vue.js – What is the correct way to use Vue 3's composition API?

Question:

With the implementation of the composition API in vue 3, I'm not very clear on how it should be used, now in the setup() method, absolutely everything that was separated before in the data , methods , computed , mounted , etc…

From what I understand the vast majority of these can be encapsulated in setup , but my main question is with the methods , these are already completely ruled out and everything must be as functions in setup ?.

What happens with the mixins , before I had several mixins which queried properties of my template with this. now this does not work because what was previously in data when found in the setup I do not have direct access from a mixin.

I have read the official documentation and guides, but I am not entirely clear how the new setup should be handled, what to put and what not to put there.

How exactly should the compisiton API work in Vue 3?

Is it good practice to mix the Vue 2 syntax with the composition api?, for example

setup()
{

    const username = reactive(
    {
        show: true,
        value: '',
        name: 'username',
        type: 'text',
        label: 'auth.username',
        readonly: false,
        validations: 
        [
            { type: "required", status: false, msgError: 'validations.required' }
        ]
    });

    return { username }
}

If I have a username attribute declared in my setup , and I need to have another attribute to query from a mixin, but if I don't have access to the setup I can declare data()

data()
{
   return {
     attr: []   
   }
}

Or is it not good practice to mix both syntaxes? I'm not completely clear about everything related to the new in Vue 3. And what is the best way to work now with the mixins?

Answer:

Depending on the version of Vue you are using, you can either use the Options API or the Composition API that Vue 3 introduced and although Vue 3 is backwards compatible with Vue 2 you have to choose between using one or the other. The Composition API, instead of separating the information into options, uses the (hook) setup() method. This hook will return an object with the elements that we want to use in the rest of the component.

In the initialization phase of the component (something like the constructor) which is equivalent to the old lifecycle phase called created , it ceases to exist in Vue 3 and instead we will use this hook, which will have two optional parameters: props and context .

props is an object with the props that have been properly initialized and defined in the component and context is an object that will contain the component's context ( attrs , emit , slots etc.).

Lifecycle hooks instead of being methods that are used as options, are functions that are imported from the vue package. Most of them keep the same name as in Vue 2, but they are preceded with an on in camelCase format ( onBeforeMount , onMounted , onUpdated , onActivated ) in case beforeCreate and created is written directly to setup() . Once imported, we can use them in setup() , passing a callback as a parameter that will contain the logic to be executed in that phase of the life cycle.

Regarding the use of mixins , I must tell you that they are considered "harmful". There is no hierarchical relationship between a mixin and a component that consumes it. This means that a component can use a data property defined in the mixin . But a mixin can also use a data property that it assumes is defined on the component. This is often the case when using a mixin to share input validation. The mixin might expect a component to have an input value that it would use in its own validation method. However, this can cause problems. What if we want to refactor a component later and change the name of a variable that the mixin needs? We will not notice, looking at the component, that something is wrong. A linter won't pick it up either. We will only see the error at runtime. Now imagine a component with a bunch of mixins . We would have to manually search for the one that would be causing problems. This is not a problem with the Composition API because we need to explicitly name any return state or method, and name collisions will be resolved in the same way as for any other JavaScript variable.

Post Views: 7
Scroll to Top