I haven't seen this discussed recently, but the ES6 Proxy object could (as I understand it) greatly simplify Vue's data binding code. Currently, it's supported in the current version of every major browser except current Safari/iOS (and that should be getting updated in a matter of weeks with WWDC right around the corner, and the Safari Tech Preview supports Proxy).
http://caniuse.com/#feat=proxy
The big benefits, as I see them are:
Vue.set
would no longer be needed.)Because it's not _quite_ universal, I propose making it an optional configuration on the VM instance for now. As I do a lot of game work with Electron and Vue, the ability to detect new properties would simplify some of my code quite a bit, and with Electron, what features the client has are always known, so I don't have to worry about different browser support.
I suspect that given browser usage these days, while Proxy support couldn't be the default for a while, it certainly could be used by a majority of users. It would even be possible to make it the default, and fall back to getter/setters if Proxy isn't supported. (There issues with that, I'm aware, as the developer might have relied on new property detection.)
Regardless, I feel having the feature would both send a message about where Vue is heading in the future and be useful to those people who can accept breaking on older browsers.
The biggest problem with Proxy is that
For point 2, ES6 Proxies can only create a separate "copy" of the original object, but this copy will fail in cases where you try to compare them with ===
:
var obj = { a: 1 }
var proxy = new Proxy(obj, handlers)
obj === proxy // false
This introduces more complexity when you are accessing nested properties - you will always need to be careful about whether a value you retrieved is the "real one" or just a proxy, otherwise it can lead to obscure bugs when you rely on ===
comparators. IMO this is even more annoying than having to use Vue.set
.
It also won't make internal binding code much simpler because how to intercept the manipulations is only a small part of the reactivity system.
If Proxies can be installed directly on an object itself, then I'm all for it. But it can't, that makes it a no-go.
I'm just gonna drop this link here
http://www.nx-framework.com/blog/public/mobx-vs-nx/
@yyx990803 I know that Vue is switching to using proxies. How were you able to overcome the transparent proxy issue? I'm working on my own library and falling into the same issue with object equalities.
I'm relatively new to Vue, but I'm using a Proxy to handle Vue.set
automatically.
var app = new Vue({
el: '#app',
data: {
model:
{
message: 'Hello Vue!'
}
}
})
var handler = {
set: function (obj, prop, value) {
Vue.set(obj, prop, value)
}
};
var dataModel = new Proxy(app.model, handler);
The below is reactive:
dataModel = ["test1", "test2"]
Where this is not:
app.model.message = ["test1", "test2"]
Most helpful comment
The biggest problem with Proxy is that
For point 2, ES6 Proxies can only create a separate "copy" of the original object, but this copy will fail in cases where you try to compare them with
===
:This introduces more complexity when you are accessing nested properties - you will always need to be careful about whether a value you retrieved is the "real one" or just a proxy, otherwise it can lead to obscure bugs when you rely on
===
comparators. IMO this is even more annoying than having to useVue.set
.It also won't make internal binding code much simpler because how to intercept the manipulations is only a small part of the reactivity system.
If Proxies can be installed directly on an object itself, then I'm all for it. But it can't, that makes it a no-go.