Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refs in Composition API could be better #196

Closed
brandon942 opened this issue Aug 4, 2020 · 1 comment
Closed

refs in Composition API could be better #196

brandon942 opened this issue Aug 4, 2020 · 1 comment

Comments

@brandon942
Copy link

The implementation of refs (to make primitive values reactive) is apparently one of the biggest issues is with the current API. The ".value" proposal is too verbose. Minified source files are going to be full of it. You really don't want to type that on every variable. The 6 extra characters can be reduced to 2 .v - the absolute minimum. I think people like me will appreciate the short form .v being at least a recognized alias, if not standard.
An even better solution, performance wise, is to combine the getter and setter functions into 1 function. Instead of the ref being composed of a container object, a property descriptor object and 2 function objects, the getter and setter, it can be 1 simple function: val() to get it, val("foo") to set it. Using it also requires at least 2 extra characters - there is no way around that, but:

(+) a normal function call is 3x faster than a getter function call
(+) it allocates less memory per ref, 1 object allocation, instead of at least 4, + the redundant "value" keys
(+) it is atomic, so no issues with destructuring
(+) it does not hide the underlying function call, the overhead that comes with it and the fact that the value lives inside of the scope of the function
( - ) you can't use syntactic sugar like x.v++

I also find the usage of proxies worrisome. They are 5x slower than normal functions and not necessary, unless you want a warning on access of properties that do not exist, which is not something everybody really needs. All that makes for a slower framework.

@posva
Copy link
Member

posva commented Aug 4, 2020

It's great you want to bring your concerns but the API design has been extensively discussed through the RFC process where you should be able to find answers to your concerns and proposals. Some of them, like .v instead of .value, are subjective, so I encourage you to find the reasons in the RFCs about composition API to get another point of view.

Benchmarks haven't been released yet but Vue 3 is way faster than Vue 2, which was already quite fast. No need to worry about that, Vue 3 isn't slow 🙂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants