Somewhat late response, yet still relevant.

First let's make an order:

If the special objects in question are treated as regular objects (some properties added/read/deleted from them) - observation would work just fine; I'm aware of fact that once there was some problem on the level of native support for such a case, but AFAICS now it fixed.
Beside being just a regular object, those objects are providing special means to hold the data within them via intrinsic APIs like set, get, delete etc. This is the case I'll be talking about right below:

I've reviewed a possibility to handle intrinsic APIs those objects as part of an observation, but decided that the they are not playing well with the current library design and will not be supported.

Especially this is the case for the sets, as there are actually no key there and the whole point of the observer is to provide a listener with the actual change and the path that has been changed. Of course, in case of sets there may be no path.
Maps are also problematic since their keys may effectively be anything - again there is a problem to generate path for such a cases.

And at the end, observation of anything passing through the internal APIs of Map/WeakMap/Set/WeakSet may be achieved in such an easy way (proxifying the methods themselves, we are talking about finite and quite small number of APIs) that I hardly can see justification to apply an observation pattern for such a use case.

I'm closing this issue with this conclusion right now, until some strong and well defined requirement of this will emerge again in any future with any reasonable solution.

Uh oh!

ES6 Map. WeakMap, Set, WeakSet support #1

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions