5 ms·
So I recently had the opportunity to use the new composition API, which will come in V3, in a project and want to share my two cents. The project had some limit
by jdellinger 6y ago
So I recently had the opportunity to use the new composition API, which will come in V3, in a project and want to share my two cents. The project had some limitations tho: no webpack and no typescript (so basically inline x-templates and pure browser JS).
Starting of with the composition API was great. No "this", easy reuse of logic via react-like "useXYZ" hooks and a general fast development. But two things really bugged me:
* You need to be really careful when passing around values and how you handle them. Destructure a Proxy object? You instantly lose reactivity. Not using a reference to proxy object in computed? Changes won't trigger the computed function. There is a lot of magic involved and while it may seem that it takes a lot of "thinking" from you, once it doesn't work you will have to rethink and maybe even ditch some of the underlying language's features.
* "ref" vs "reactive", where "ref" is used for primitives which need a proxy object wrapper and "reactive" is used for objects/arrays. Now, my primary problem is that you again have to use specific operations based on whether your using ref or reactive. A "ref" array can be easily set to an empty array via `arr.value = []`. If you try this with a "reactive" array, you will lose reactivity; you would have to use `arr.length = 0`.
TypeScript detects a lot of those pitfalls and, IMO, it is essential when using the composition API. Without it, there is too much invisible magic happening.
- typingmonkey 6y agoYes I fully understand this. Also with vue2 you often get problems with the internal version of "array" that is wrapper around a normal array to detect changes.
- creatio 6y agoHow so?
- brylie 6y agoPerhaps updates to the array content don't trigger reactive computations? Not sure really.
- nnevala 6y agoAt least a year or so ago, when I was still working on a Vue project, some external libraries didn't work with Vue reactivity due to the way it was implemented by overriding Array built in methods. I think we ran into this issue with some lodash functions.
- midrus 6y agoI used to prefer (and by a lot) Vue more than React because of its simplicity and completeness (router + store + everything you need). After trying to use v3 for a new project and trying out the composition API, I've gone back to React. With v3, and the composition API, to me, it lost all of its appeal (being simple, easy and complete). Now to me it has the worst of both worlds... it's not as easy anymore, has a lot of gotchas and conceptual overhead.
- MatekCopatek 6y agoAs far as I understand the Composition API is purely opt-in and aimed at cases where you want to trade simplicity for power/control. The Options API is still the default and remained pretty much the same.
- brylie 6y agoThe composition API is opt-in, but will likely be the de facto standard if/when the majority of projects and tutorials use it.
- uallo 6y ago> will likely be the de facto standard if/when the majority of projects and tutorials use it. Why would you think that? To me it sounds like a completely unbased opinion and goes agains everything that I read in the v3 documentation or in numerous discussions. > Possibly the biggest change is our new Composition API, which is entirely additive- the previous Options API will continue to be supported, as the Composition API is an advanced feature. https://v3.vuejs.org/guide/migration/introduction.html https://v3.vuejs.org/guide/migration/introduction.html The Composition API is the last item in the API reference, the Options API is positioned much more prominently. https://v3.vuejs.org/api/options-data.html https://v3.vuejs.org/api/options-data.html In the Guide, the Options API has its own section while the Composition API is nested within the "Advanced Guides" section. https://v3.vuejs.org/guide/introduction.html https://v3.vuejs.org/guide/introduction.html
- 6y ago
- WealthVsSurvive 6y agoHaven't looked @ v3, but I have a question: why would the Proxy object be available to destructure? Why not use a revocable proxy that is only a proxy when it's being modified through accessors? Why would any state management library author expose a Proxy? It should expose ubiquitous, useful, human-readable, undecorated save for maybe Symbols, JSON.