joe at trusktr.io
Tue Jul 24 17:49:58 UTC 2018
> 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
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
- 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).
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
> > the call (i.e. not a Proxy), and other than monkey-patching
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss