rfcs

This is not a proposal per se but I would like to raise some points about always calling on the value returned by (return value that I'm gonna name in this issue). Code is right here: https://github.com/vuejs/vue-next/blob/master/packages/runtime-core/src/component.ts#L355 Intro: what it achieves Calling on the return value of enables: (deep) reactivity on every scope field, even those that aren't in . reactivity on field addition/removal. unwrapping values for easy consumption in template. (impl. detail) turns the scope into a proxy. 1. Missed optimizations makes every field and property deeply reactive by default. This can be counter-intuitive and misses some optimization opportunities. Consider: I would expect to be a reactive property, while is a non-reactive array. Maybe some read-only objects I got from server and I don't intend on modifying. This gives me total control over the reactivity, and only what I intend on modifying is actually reactive. But the scope will actually be fully reactive. This means every object in is gonna get wrapped in a proxy. Every UI binding is gonna create change listeners. All this work could have been avoided. Of course there's that enables me to avoid that if I really want to, but the default behavior doesn't feel intuitive. It's also slightly inconsistent. Why create reactive data in , if it'll be reactive anyway? Answer: you need to create reactive data if you intend to use it inside , e.g. in or . Otherwise you don't have to. It feels weird and arbitrary. 2. To value or not value? Speaking of inconsistency, Whether you have to use or not is also a bit inconsistent. Some users may deviate just slightly from the recommended pattern and do this: Using in kind of works, but cannot work everywhere. Inside , if you create a for example, works if you do , because is and is a . In the template on the other hand, works if you do because is and the has been unwrapped. Of course, the solution is to not use but refer to directly. You can be sure some users will fall into this trap. Using doesn't solve everything either, as we fall back into the inconsistencies of 1. If I declare something without a inside , say then event handlers that set it on will escape the change tracking, despite everything I said in 1 (since they would access the target of the proxy directly). 3. Unwrap refs ourselves Point 2 shows that usage can become confusing. History (I'm referring to Knockout here) also shows that devs don't like having accessors everywhere: they're verbose and it's easy to forget or misuse them if you don't have a type system (e.g. you write plain JS). So you may be tempted to do this: And now you can use all you want without ever writing a . This works great, but at this point doing on the returned value is a noop. If we go back to 1, and you want to have easy, fine control over what property is reactive and which one is not, you may be tempted to write your own function, say that either transform every field holding a ref into a getter/setter that unwraps them; or wrap the thing behind a proxy that does the same. In theory this is a great solution but the automatic will uselessly wrap this into a proxy. Additionally, every access (read/write) to will be double-tracked, once by the proxy, and once by the hidden inside. 4. Class-based components I totally understand why Vue 3 is gonna stay away from decorators, at least until they advance to a further stage. That said, some users may still think using decorators in their project is ok. They might like the following syntax: It's not very complicated to write the decorators that make this work. It won't be long before someone publishes them and that's fine. There are two issues here: The result of this code pattern suffers the same problem as the technique described in 3. Should users use private fields (they're becoming a thing); and should the proxy + private fields incompatibility not get addressed by TC39; then the pattern will fail miserably. As far as I can tell, if was not called on the scope automatically, this would work perfectly. Conclusion I _love_ the explicit control given by and the new Composition API ❤️ In fact, I've been wanting this in a modern framework since the day I stopped using Knockout. I feel like the automatic call on the scope is removing a lot of that explicit control -- or making it a lot more verbose to reclaim ( and co.). First idea that comes to mind is that users should be responsible for the precise shape of their scope, i.e. they need to call themselves if they want to. It means you can access the same object (proxy or not) in the template and in . Many people will often call anyway, because it's more convenient than doing lots of and . Conceptually, it's not harder than explaining ... Also: I think the (actual name to be defined) function I mentionned above should probably in Vue core. It's a better choice to call on the scope than .