> 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
