Giter Club home page Giter Club logo

Comments (2)

gullerya avatar gullerya commented on September 18, 2024

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?

from object-observer.

gullerya avatar gullerya commented on September 18, 2024

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.

from object-observer.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.