Proxy is limited, because it won't intercept deleteProperty or others as part of a prototype, so you need to replace the object with a proxied object, which is not exactly the same as Object.observe.
On Tue, Jul 24, 2018 at 7:50 PM /#!/JoePea <j...@trusktr.io> wrote: > > But yes, **if** you know the names of the properties in advance > > I don't because I'm using [`element-behaviors`]( > https://github.com/trusktr/element-behaviors) (which I wrote). Behaviors > can be arbitrarily added and removed from an element, behaviors can observe > any arbitrary attributes on an element, but the difficulty is in behaviors > observing arbitrary properties on an element regardless of if the props > already exist. Because an element may have any number of unknown behaviors > added to it in the future, there's no way to pre-meditate the set of props > that will be observed. > > > The only way I can think of that might work will only work if all > actions against the observed object happen through methods of the observed > object's prototype > > If I drop support for IE, maybe Proxy will help me. > > The thing is, what are the implications? It seems a bit tricky to > introduce a Proxy somewhere in the middle of a class hierarchy. > > - How do I return a Proxied this from a class in the middle of a hierarchy > without changing patterns? Seems like I could use a single base > `constructor` then move all construction logic to a `construct` method > called by the base `constructor`, to make things easier. I do a similar > hack now anyways in order to make ES5-style classes work with native Custom > Elements. > - How do we proxify a class prototype when using ES6 classes? Do we just > `SomeClass.prototype = new Proxy(SomeClass.prototype, handler)`? Any > implications of that? > - Seems like `Object.observe` would've just been the easiest way to > achieve what I want, if that hadn't been dropped. > - I currently use `MutationObserver` to observe HTML element attribute > changes, which is the like the equivalent of `Object.observe` for DOM. But > the downside of this is that it only covers attributes, not instance > properties. Plus, attributes are always strings, incurring performance > overhead. And all the new frameworks delegate to instance properties, > bypassing attributes, therefore bypassing MutationObserver observations. > > Seems like `Object.observe` would be the simple magic tool that I keep > circling back to. > > In my specific use case (the behaviors), I'd just like to observe > arbitrary instance props so that I can get performance gains from not > observing attribute changes in cases where a framework is using instance > props instead of attributes. Again, attributes are arbitrarily observable, > while props are not. > > If I am okay to drop support for IE (I'm a little skeptical), then I'd > like to consider how Proxy might help, but it just seems more complicated > that it ought to be compared to `Object.observe` (which my behaviors could > use to observe elements). > > */#!/*JoePea > > > On Tue, Jul 24, 2018 at 10:17 AM T.J. Crowder < > tj.crow...@farsightsoftware.com> wrote: > >> On Tue, Jul 24, 2018 at 6:01 PM, /#!/JoePea >> <j...@trusktr.io> wrote: >> > Is there a way to polyfill `Object.observe` in such a way that the >> object >> > before observation is the same reference as the object being observed >> after >> > the call (i.e. not a Proxy), and other than monkey-patching >> getters/setters? >> > >> > Is defining getters/setters the only way? >> >> Even that doesn't really polyfill it, because `Object.observe` got >> notifications of changes when new properties were created as well. >> >> But yes, **if** you know the names of the properties in advance (the >> "shape" of the object, I believe, is the current parlance?), and if you >> want notifications of changes just to those properties, I think >> monkeypatching will be your simplest and most successful approach. >> >> If you need to catch additions as well, I don't think there's any >> solution other than diffing, which is quite yucky. >> >> -- T.J. Crowder >> > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
