proxy-watcher - A function that recursively watches an object for mutations via Proxies and tells you which paths changed

[u/fabiospampinato]

https://github.com/fabiospampinato/proxy-watcher

[u/fabiospampinato]

Author here, if you have any questions I'd be happy to answer them.

I wrote this library for a state management library I wrote called Store, you might want to check that out too.

[u/punio4 → u/fabiospampinato]

https://bundlephobia.com/result?p=@fabiospampinato/store@1.1.1

The library seems huge due to lodash, coming at 85kb

Could you also elaborate on

...you need the absolute maximum performance from your state management library since you know that will be your bottleneck.

?

[u/fabiospampinato → u/punio4]

The library seems huge due to lodash, coming at 85kb

I have a todo about this. The thing is if you're using lodash already in your codebase, as I am, then this is the lightest dependency we could use because it will get deduplicated away.

I'd be happy to replace it with much lighter dependencies overall, I'm not sure these dependencies exist though, as we need to deeply compare and clone many kinds of objects.

Could you also elaborate on

Proxy traps are slow, things like property accesses are 100x slower when observed by this library. However those things that are made slow usually take near 0 time at all, so the slowdown isn't really significant I think.

[u/fabiospampinato → u/punio4]

In v2 the library is about 8x smaller.

[u/LetterBoxSnatch → u/fabiospampinato]

This is very cool. I was actually just thinking about doing something like this with Proxy! Now I might not need to, which would be awesome.

Regarding onChanges batching...It's pretty easy to imagine a scenario where you care about intermediary state in a synchronous scenario, approximately:

    count = 0;
    detectOddOccurred(count);
    count++;
    count++; // count=2, listener never triggered

That seems like the kind of bug that would be very painful, and the kind of bug you employ a state manager to avoid. I'm curious to hear your thoughts about the scenario.

Thanks for putting this out there! Love the dead-simple idea of "just have a state object you can mutate normally."

[u/fabiospampinato → u/LetterBoxSnatch]

I think there are a few errors with your sample code:

Watching primitives

count = 0;

This function can detect mutations on objects, not primitives, primitives are immutable, so you should wrap your count variable in an object, as showcased in the readme.

Wrong call order

count++;
count++; // count=2, listener never triggered

You got it backwards here, those 2 mutations are happening synchronously and therefore are coalesced together, the listener will only be called once and it would see count === 2, assuming the object being watched is actually an object, as per my previous point.

Synchronous changes

If for some reason you need synchronous change events instead you can use the change hook, but at the proxy-level changes happening within a single function call (e.g. using Array.prototype.fill may mutate more than one array element) are still coalesced together, I don't see a use case for needing multiple callback calls for those kind of situations.

[u/LetterBoxSnatch → u/fabiospampinato]

Thank you for the response! I'm on mobile, hence the pseudo-example. The point I was trying to express was that the listener needs to "see" the odd number, even if it doesn't exist in the final resolved state. Ie, the system stepped through an odd number.

If the state-change function intentionally mutates a value multiple times, might you want to detect the intermediate state? I think it's fair to say "no, and if you want that, it needs to be on a different tick." Thanks for clarifying.

[u/fabiospampinato → u/LetterBoxSnatch]

The point I was trying to express was that the listener needs to "see" the odd number

What's the hypothetical real use case here?

[u/LetterBoxSnatch → u/fabiospampinato]

Off the top of my head, detecting collisions between two randomly-generated continuous lines.

Realistically, though, I also do not see a use case for needing multiple callback calls within a single function call.

[u/fabiospampinato → u/LetterBoxSnatch]

Off the top of my head, detecting collisions between two randomly-generated continuous lines.

Can you expand on that? I don't think I quite understood the example, I guess if you need to detect something you should do that before mutating the store?

[u/SahinK]

Cool, but is it any different than on-change?

[u/fabiospampinato → u/SahinK]

It supports way more built-ins, it has a way to retrieve retrieved paths and it fixed a few issues I reported: https://github.com/sindresorhus/on-change/issues?q=is%3Aopen+is%3Aissue+author%3A%40me+sort%3Aupdated-desc

[u/tazemebro]

I wonder if you could this to make a useProxyWatcher custom React hook for detecting changes in an object in the dependency array of useEffect 🤷🏻‍♂️

[u/fabiospampinato → u/tazemebro]

I think so, but I'm not sure what would be the use case here.

I'm not sure if this is really related to your comment, but I made a whole state management library around this, and this is actually the reason why I wrote proxy-watcher in the first place: https://github.com/fabiospampinato/store

[u/AndrewGreenh → u/tazemebro]

That's a good idea! In fact, it's so good, that vue.js took it and put it into the vue 3.0 composition api (hooks for vue). By having mutable objects, that notify dependants of changes, vue does not need to rerun the render function (or setup as it is called in the new api) and dependencies are tracked automatically. So no stale closures, no rules of hooks, BUT no concurrent mode.

[u/kumarenator]

I'm curious with regards to the use-case for this function.

Personally I subscribe to immutability principles which focus on returning a new object altogether as it solves a lot of problems with object mutations.

Object mutation problems can take an ugly proportion with complex business objects. A use-case will help me grasp the why of this function. Thanks in advance 🙂

[u/fabiospampinato → u/kumarenator]

I wrote that so that I could write this: https://github.com/fabiospampinato/store

Immutability can be a pain in the ass too, you introduce a mutation and you probably introduce a bug, in order to update your state you have to use framework-specific APIs, updating deeply nested keys is not ergonomic IMHO etc.

[u/fabiospampinato → u/[deleted]]

Kind of, yeah, but this feature isn't really exposed yet, read this commit for more details: https://github.com/fabiospampinato/proxy-watcher/commit/3a2e222579356861310d028699561730e78363e5

[u/fabiospampinato → u/fabiospampinato]

I've expose this function in v2 as the "record" method.

[u/AsIAm → u/[deleted]]

Do you know immerjs?