Hacker News Reader

Comment by plopz | Hacker News Reader

I found that Vue 2 was very nice when I was playing with it for simple things as a toy. But as soon as I started to try more complicated things, the reactivity system just fell apart. There are just some fundamental mismatches between how JS references work and how the Vue 2 reactivity system works. Once you learn the pitfalls however (like never de-reference in data, only access shared state through computed, dont bother trying to use data structures like Map or Set), it becomes nice again although in the process it loses its luster.

I believe Vue 3 is supposed to fix much of this, but its unclear whether its going to be backwards compatible.

View on HN

I agree. I’ve been burned by the reference management and reactivity. Vue 2 doesn’t let you manage your data separate from Vue it’s self, the data tree needs to be inside Vue.

yep. thats intentional... you can have multiple instances of vue going and it also plays nice with jQuery so that you can add Vue into your project without messing everything up.

Also worth noting its not 100% true you can't manage your data separately you just need to manage the reactivity yourself.

Do you mean writing your own get/set observables? I've looked at how Vuex does it and internally it just wraps the data in a Vue instance. https://github.com/vuejs/vuex/blob/dev/src/store.js#L280

I don’t understand how (or why) managing the reactivity of data and having multiple instances are coupled.

Also, implementing your own reactivity is very unintuitive. You need to implement your own “diffing” (is this change worth rendering) to know when to force Vue to render. This is definitely not how Vue was intended to be used.

Correct, but it's the same with alternatives.

E.g: redux uses a react provider to inject the data into the component tree because of this. Vuex does the same for vue.

Untrue. Using Mobx your model can be defined completely independently from your view layer like React.

No it isn’t.

React will simply render the object you give it. That means that React doesn’t need to know when data changes, it simply renders the ui, diffs it to the current ui and applys the changes.

Unless your using component state but even then, it’s the rendering that measures change. The act of updating the state just lets React know “time to see if anything important changed”. Vue seems to tra Co data changes granularly which means it needs to understand the change at the point if mutation. This means it needs control of the data you want to render.

True, but I don't think that's such a bad thing.

I find the limitation to only use dumb pojos much worse. AFAIK that is going to be fixed in Vue 3 since the reactivity system will use Proxy instead of getters and setters.

Fair enough. I do, it makes managing relational data that isn’t stored hierarchically in a tree much harder.

It is possible to keep the data inside of a seperate class. I have an app where I needed to observe a few properties of a class but wanted to keep it completely standard js so it could be used outside of a Vue app. I created an object in Vue's data and referenced some of the class properties, it works fine and changes are reactive in both directions.

The issue is references, if you de-reference in the data function, you can now never change that reference because Vue's reactivity won't see the change.

    let external = {foo: {bar: 'something'};
    new Vue({
      data: function() {
        return {
          ref: external.foo.bar
        };
      }
    })
    external.foo = {bar: 'something else'};

This is fine if there is a 1-1 relationship between the data object and the components (though persistence becomes interesting to manage then). But if you have hierarchies with lists of data that often change this doesn’t work. Vue2 doesn’t track changes across array access or objects that didn’t exist when the heirarchy was built.

One big issue for me has been that your data layer needs to know about and use Vue, which seems unintuitive as Vue is a UI library.

I believe backward compat is a goal of vue 3.

In all honesty, the pitfalls are not that many, easy to understand, learn and avoid or get out from.

I spent way more time trying to figure out doing even basic things in react than debugging reactivity in vue. Espacially since the later has a fantastic doc and a small api.

Reply on news.ycombinator.com