Polyfilling Object.observe

[#!/JoePea]

> Because you are doing it wrong.

Yeah, because using Proxy isn't simple like using `Object.observe`. I'm
just showing that this is all extremely easy to do with `Object.observe`.

> What you really want is to have new Foo() return a Proxy... which is
counter-intuitive, admittedly, because we're all taught that a constructor
should never explicitly return a value.

I mentioned earlier I don't want to modify my entire class hierarchy just
to make part of it observable, and have to tell people who extend my
classes to change their patterns (it's a breaking change).

Again, not a problem with `Object.observe`.

> membranes

I just read the articles. That's much too complicated. Plus, it only works
on objects that are designed to be proxies before they are passed to other
code.

I want to do this:

```js
import anyObject from 'any-package-on-npm'

Object.observe(anyObject, console.log)

// logs stuff every time any-package-on-npm modifies the object.
```

If I use proxy, this is what happens:


```js
import anyObject from 'any-package-on-npm'

const membrane = new ObservableMembrane({
  valueMutated: console.log
})

membrane.getProxy(anyObject)

// nothing, silence, crickets
```

`Object.observe` just works, and is soooooooooooooooo simple. I won't shoot
myself in the foot with it. I'd like to make a one-way data flow
implementation with it, using 3rd party web components, and
`Object.observe` would make this _incredibly simple_.

*/#!/*JoePea


On Sat, Jul 28, 2018 at 8:54 AM Alex Vincent <ajvincent at gmail.com> wrote:

>
> `Proxy` is powerful, but it's not as good as `Object.observe` would've
>> been for some very simple tasks.
>>
>> Every time I wish I could use `Proxy` in a simple way, there's always
>> some issue with it. For example: https://jsfiddle.net/trusktr/hwfontLc/17
>>
>
> Because you are doing it wrong.
>
> Proxies can *only* observe on the object that they're created for.  By
> setting Foo.prototype to a proxy, you can only observe operations on
> Foo.prototype, not instances of Foo.
>
> What you really want is to have new Foo() return a Proxy... which is
> counter-intuitive, admittedly, because we're all taught that a constructor
> should never explicitly return a value.
>
> This problem has been solved, a few times, with the introduction of
> membranes in JavaScript.  In that environment, you would start with Foo and
> wrap it in a membrane proxy. Then, in invoking new Foo(), the "construct"
> trap of that proxy would return another roxy automatically, probably using
> the same proxy handler but a different proxy target.
>
> If it's any consolation, proxies are in general very hard to work with.
> You're only scratching the surface here.  I recently gave a talk at TC39
> (the standards body for ECMAScript) on membranes.  One key takeaway is that
> the overhead in dealing with membrane-oriented proxies really is better off
> left to a library built for that purpose.
>
> Tom van Cutsem is working on an article summarizing the current state of
> membranes.  I'm not sure if he has approved its general release yet, so
> stay tuned...
>
> Alex Vincent
> Edmonds, WA (on vacation)
>
> --
> "The first step in confirming there is a bug in someone else's work is
> confirming there are no bugs in your own."
> -- Alexander J. Vincent, June 30, 2001
> _______________________________________________
> 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/20180728/c4f1af80/attachment.html>