Compatibility build: How do we replace the component proxy's functionality?

[LinusBorg]

So I was wondering about this ... and it's more a question of curiosity than me spotting a problem but ...

We will provide a compatibility version of the observer package that will implement the 2.0 Reactivity system (getters&setters) that people can use for browsers that don't support Proxy (read: IE).

However, also heavily rely on Proxy in the runtime-core (componentProxy.ts)

With this implementation, we don't have to actually add properties to the component instance for each prop and $data property, computed property and so on. We can just catch get and set access in the component's proxy.

But for a compatibility build, we would have to replace this behaviour with code that dpoes add getters & setters to the component instance, right?

In the current implementtion I don't see a clean / easy way to exchange this like we plan to have it for the observer package, do we (@evan) have a plan for how to approach it?

[LinusBorg]

As a sidenote, I realized that we also use WeakMaps in a couple of places outside of the observer package.

Since WeakMap can't be properly polyfilled(?), should we choose a different implementation or am I missing something`

[Justineo]

core-js has a built-in WeakMap polyfill: https://github.com/zloirock/core-js/blob/master/packages/core-js/modules/es.weak-map.js

[LinusBorg]

I see. I'm a little suprised (positively!) that this behaviour can in fact be polyfilled, good to know.

So we would require some polyfills for the compatibility build, for Set, Map, WeakMap etc. Seems fair in order to drag ppl into the future :-P.

[yyx990803]

@LinusBorg we will fallback to actually defining everything on the instance, but only when we detect the runtime doesn't support native Proxies. That logic will live in runtime-core and be included/excluded via a build time flag.

[LinusBorg]

Great.