Polyfilling Object.observe

Andrea Giammarchi andrea.giammarchi at gmail.com
Tue Jul 24 21:14:52 UTC 2018

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 <joe at 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.crowder at farsightsoftware.com> wrote:
>> On Tue, Jul 24, 2018 at 6:01 PM, /#!/JoePea
>> <joe at 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 at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180724/6841bb2e/attachment-0001.html>

More information about the es-discuss mailing list