Render function vs expose

[AimForNaN]

https://vuejs.org/api/composition-api-setup.html#basic-usage

According to basic usage, I can expose local variables by returning them from the setup function.

{
    setup() {
        const foo = 'bar';
        return { foo };
    },
    mounted() {
        console.log(this.foo); // prints "bar"
    }
}

https://vuejs.org/api/composition-api-setup.html#usage-with-render-functions

But then we get into render functions. Exposing the same does not work.

{
    setup(props, { expose }) {
        const foo = 'bar';
        expose({ foo });
        return () => h('div');
    },
    mounted() {
        console.log(this.foo); // prints "undefined"
    }
}

Should I file a bug report? This seems counter intuitive. What problem is expose supposed to solve if not the kind similar to that expressed here?

[baiwusanyu-c]

I don't think this is a bug. expose just exposes the incoming properties and uses these properties at some point (such as reading and using them in the parent component), as far as I know, expose will not be in the composition api and option api to expose the incoming attributes. In the example you provided, the reason why the value can be printed in the hook function mounted is because you returned the value in setup, not because expose exposed the value

As you can see from the following example, the value of foo can be printed out not because of expose

<script>
  import { ref, defineComponent } from 'vue'
  export default defineComponent(
  {
    setup(props, { expose }) {
        const foo = 'bar';
        expose({ foo });
        return {
          foo: 'foo'
       }
    },
    mounted() {
      console.log(this.foo); // prints "foo"
    }
})
</script>

[AimForNaN]

Now, if you could get mounted() to also print out "bar" by returning a render function from setup(), that would be great. (Though, I already have an idea on how to do it.)

[LinusBorg]

This is working as intended. expose() does not have any effect on the component internally. it's job is to make content from setup available to any external code that holds a reference to the component's instance, i.e. a parent component using a template ref on it.

Returning a render function from setup and mixing that with options API is not a good combo, you will not be able to access anything from within setup in the Options API code, so just - don't do that. Chose one API (per component, at least)

[AimForNaN]

According to the documentation, accessing a property from mounted() that was returned from setup() is listed under the composition API. Therefore, by definition, it is purely of the composition API. Even the documentation recognizes the problem with returning a render function. However, since expose() only covers template refs, we end up losing a feature of the composition API when we return a render function. This not only becomes counter-intuitive, but creates a problem. In the first case, we are given access to the returned state on a component level, which is also exposed to the parent by template refs. But when returning a render function, there is no way that I can see to achieve the exact same thing. It seems odd to recognize the problem, but provide an incomplete solution, and one that suggests potential redundancy.

The following redundancies are implied: mounted hook is available for use, but should be considered deprecated in favor of onMounted() (for in the case of onMounted we would at least be able to print out "bar"). Returning an object is available, but should be considered deprecated in favor of expose(). But to acknowledge the usefulness of returning an object at this point is to confirm my concern. Yet, confirmation is nullified where there exists no interest to resolve the problem. Yet, why should I import onMounted when I can simply use mounted and spare myself an import?

The only solution to my problem is: Don't return a render function and simply rely on <template> to render my component. But that either implies further redundancy or affirms a previous redundancy. The previous one being that returning an object from setup() should be assumed as deprecated (in favor of expose()), but then you wouldn't return anything at all, ever. The alternative redundancy being that returning a render function should be the one to be assumed as deprecated in favor of <template>, therefore removing the deprecated assumption for returning an object. But returning an object would make expose() redundant.

[LinusBorg]

I have trouble following you, it seems to me you are over-complicating this.

Just to stress: Nothing is deprecated.

It seems odd to recognize the problem,

I haven't recognized it, I don't see one. Maybe the following is unclear to you so far?

Render functions are available to both composition API and Options API. You can return it from setup or add it directly to the options object like we are used from Vue 2:

export {
  render () {}
}

and the expose feature is also available to Options API, no setup function required.

So whichever API you choose, you can use lifecycle hooks, reactivity, render functions, templates etc. There's really nothing that Composition API would not allow you where Options API did.

It's just that the two being meant to be used on their own, mixing them (just to "spare myself an import") is not fully supported. Choose one.