DEV Community

Thought on Vue 3 Composition API - `reactive()` considered harmful

YCM Jason on October 19, 2019

Vue.js stands out from other frameworks for its intuitive reactivity. Vue 3 composition api is going to removing some limitations in Vue 2 and prov...

Read full post

ushironoko • Oct 19 '19

In the option api, each option is self-evident at the top level, making it easy to track reactive data consistently in any code. (This is the biggest advantage of option api)
Since all new APIs are wrapped in setup and reactive data is ejected from the extracted functions, it is not obvious which API the data comes from. By considering .value as a prefix, tracking reactive data can be made somewhat easier.

Scott Molinari • Oct 24 '19

This is why the best practice of using "useXXX" has been suggested. Any object called "useXXX" is considered reactive.

Scott

Chris Nicola • Dec 4 '19

I guess I have a few questions about this.

1) Why can't you use reactive to declare multiple variables as you are doing with ref and computed. I'm not sure I see why that is an advantage unless I misunderstand the usage.

2) Why, in your blog post example did you chose to declare a reactive array directly instead of reactive({ blogPosts: [] }) which would have made more sense and have largely the equivalent behaviour to using ref.

The API RFC document seems to explain fairly well where reactive and ref should and should not be used. I don't really see where reactive could really be dangerous outside of simply not understanding how it will behave relative to ref and computed.

vue-composition-api-rfc.netlify.co...

Mikhail Panichev • Oct 24 '19

Nice article, thank you!

To be honest, I”m a little disappointed in the new reactivity system. I think if it’s immutable, the final code is more strict, predictable and cleaner. Especially in case of junior devs. I mean, deep object reactivity is unnecessary because if you have something like users[index].info.cats.push(newCat), you more likely have spaghetti code and should restructure this component.

By the way, will deep object mutation trigger updates only in specific child component?

YCM Jason • Oct 24 '19

Why would .push more likely to introduce spaghetti code?

Will deep object mutation trigger updates only in specific child component?

Yes.

A component will only re-render if the dependencies of the render function are changed. So if a child component do not depend on the "deep object mutation", then it should not be re-rendered.

ChaDonSom • Oct 19 '19

I've started using ref for the same reasons.

Ref is easier & cleaner.

I do wish we could do without .value, but every time I use reactive it comes back to bite me, so I'd much rather explicitly write .value than have to figure out the implicit.

Debove Christopher • Nov 9 '19

Yeah I did have the same problem when I wanted to use a computed on a reactive array

// This computed won't update
const todos = reactive([])
const uncompletedCount = computed(() => todos.filter(t => !t.completed).length)

// Updates correctly the computed
const todos = ref([])
const uncompletedCount = computed(() => todos.value.filter(t => !t.completed).length)

Mateusz Kwiatkowski • Mar 20 '20 • Edited

Does anyone knows how to make this example work? It seems that computed with reactive data doesn't updated at any but why is so? (Strange enough I can see in Vue DevTools, that sometimes the value for this reactive computed get somehow updated, but as soons as I open DevTools it won't anymore).

It will only work if inside reactive we define an object because, as I understand it, reactive expectes some properties to work with,. Therefore there must be an object passed. I think Vue should handle this case much better and output some sort of an error or a warning to the console.

For example the code below will update the value as intended:

const todos = reactive({
  state: []
});
const uncompletedCount = computed(
  () => todosReactive.state.filter(t => !t.completed).length
);

Darryl Noakes • Sep 13 '21

An array is an Object.

Sylvain Pollet-Villard • Nov 7 '19

Neither reactive nor ref feel like a good solution to me. We know that the options API is very approchable by beginners, which makes Vue successful, so as a consequence the Vue team had to deal with a lot of beginners mistakes ; for the options API, it was often a misunderstanding of how the this keyword works. So this has been flagged as a footgun and is avoided as much as possible in Vue 3 RFCs.

Yet I feel like using this in setup would have solve so many trouble, while being much closer to the remaining options API:

this.count = 0
setTimeout(() => this.count++, 1000)

this.errorMessage = null
watch(count, count => {
  if (count > 10) {
    this.errorMessage= 'Larger than 10.'
  }
})

it works exactly like any other component option
no need to return explicitely the bindings, which is something I often forget when using Composition API
no trap like forgetting .value or destructuring reactive objects ; the only trap is when the context changes, but:
- it's a language issue, not a Vue issue. It's something the developer will have to learn in JS at some point anyway
- arrows functions are awesome, we use them anywhere and they don't rebind this

I believe the difficulty in composing logic while keeping the same execution context is overstated, nothing that can be fixed with a simple .call(this). And again, this is a general JavaScript issue, nothing specific to Vue. Devs will meet the exact same issue on the logic/services parts of their app, if they mix OOP/FP style, which seems to be a current trend.

Guillermo Peralta Scura • Oct 19 '19

Another great benefit of refs is that if you return an object where each property is a ref from a composition function, you can destructure it safely.

WORMSS • Oct 19 '19

Are the return types from ref().value recursive read-only?
Or are they still mutable? Are they reactive if so?

Guillermo Peralta Scura • Oct 19 '19

ref.value is mutable, and if the inner value of your ref is an object it is deeply reactive. E.g.: myObjectRef.value.bar.foo = "5" will trigger any watcher on myObjectRef

YCM Jason • Oct 19 '19

If it is a computed ref, then I believe it will be recursively read-only.

Scott Molinari • Oct 24 '19

There is a helper function for destructuring a reactive object called toRefs(). So, in the end, you can just use reactive objects and destructure them with toRefs().

Scott

Vitaly Dub • Jul 30 '20

Have you considered this way of working with "reactive"? In my opinion it's better than use .value but have all the best of "ref" kind of declaration

<template>
    <div id="app">
        <input v-model="val" />
        {{ $val }}
    </div>
</template>

<script>
import {reactive, computed} from "vue";

export default {
    setup () {
        const state = reactive({});

        state.val = "abc";
        state.$val = computed(() => `--${state.val}--`);

        state.arrayVal = []; // array is reactive and you can reassign it

        return state;
    },
};
</script>

YCM Jason • Aug 2 '20

Yes. I actually proposed that to Evan before too. But after actually using the composition API, I was surprised to find ref much more natural to use. Having said that, using a state object is totally valid pattern tho!

Andrey Krasnov • Dec 23 '19

this should work the same way as ref()

const blog = reactive({posts: []})
blog.posts = await fetchBlogPosts()

YCM Jason • Aug 3 '20

Exactly! So just use ref!

KjetilHaaheim • Nov 20 '19

I appreciate your input, and Vue is definitely not holy in my eyes. It is a framework amongst many, your comment was simply off topic when the discussion is clearly about Vue3 Composition API, and not a debate about which X is better than Y. The agressivity in your reply, you can take elsewhere.

Eric Bishard • Oct 20 '19

This comment is a bit out of place..

Ari Leo Frankel • Nov 5 '19

Thanks for this article and for starting the enriching conversation below.

At least for me the resolution of the first image is such that I'm finding it hard to read. Do you think you could update that image to a higher res and/or link out to the src?

YCM Jason • Nov 5 '19

Hi.

The image is intended to illustrate the problem with option api. I took the image from the vue composition api rfc. See here.

KjetilHaaheim • Nov 20 '19

"I dont have comments on this post", "not interested in latest developments in Vue"
Then why are you commenting on this post, which is about Vue?

You are also not interested in changes to Vue, yet you are comparing it to another framework. It is hard enough to get professional environments to use Vuejs instead of React, without mixing other libraries into the mix. Good job, sir.

Sdu • Oct 27 '19

What I love about this post is that you don't need to have learnt vue 3 to understand what's going on, in fact, I just learned something new here, important concepts rather. Thanks for this

Greg Ward • Dec 14 '20

Appreciate the article. Definitely something I am attempting to work out in my own code as we speak.

chenkai • Mar 3 '22 • Edited

On the other hand, even if reactive is used, ref cannot be avoided. For example, computed returns a ref.I prefer to use the same api