Giters

gullerya / object-observer

Object Observer functionality of JavaScript objects/arrays via native Proxy

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

ES6 Map. WeakMap, Set, WeakSet support

devmondo opened this issue · comments

commented

Hi,

great library there, after making some tests, all is working great, except no support for the for mentioned new ES6 Data Types, is there a possibility to support them?

thanks in advanced.

commented

Hi,

Thanks for a feedback!

I've not planned it and actually my first intuitive answer was that those objects are not part of the functionality targeted by object-observer (OO) utility, but let me do some checks to see what's the gap.

2 questions for clarification:

  1. Can provide the simplest use-case where such on observation would be useful?
  2. All of these classes are able to receive a changes by both, their intrinsic APIs (set, add), they are also may be added new properties just as any other object in JS (var m = new Map(); m.prop = 'text'). I assume you are interested in an ability to observe the changes made by the APIs, right?
commented

Somewhat late response, yet still relevant.

First let's make an order:

  1. 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.
  2. 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.