4 ms·

> Nice little library, but as it's signals based, it would be nice to make it compatible with the signals proposal (https://github.com/tc39/proposal-signals htt

> Nice little library, but as it's signals based, it would be nice to make it compatible with the signals proposal (https://github.com/tc39/proposal-signals https://github.com/tc39/proposal-signals) Based on the current proposals, it seems that a signal can only contain a single atomic value, for which changes can be tracked. Aberdeen's `proxy` can efficiently wrap complex data structures (objects within arrays within objects, etc), tracking changes on the level of primitive values (integers, strings). For that reason, I wouldn't really call Aberdeen signals based. Yeah, "what data to sync and when" describes the problem quite nicely! And indeed, it's entirely different from this library, except that I have a partial solution in mind that may fit Aberdeen rather well... We'll see. :-)

MrJohz 1y ago
Aberdeen's proxy is essentially an object of nested signals. In general: proxy({ name: "Foo", email: "bar", }); is semantically equivalent to new Signal({ name: new Signal("Foo"), email: new Signal("bar"), }); The syntax for getting a value will look different in each case, but using Javascript proxies you can fairly easily wrap the latter in such a way that it looks like the former. That's what happens with SolidJS's createStore utility, and I assume it's what's happening here as well. Aberdeen looks like it's taking Vue's approach of making the proxy/automatically nested case the default, which is typically more convenient as nested reactivity is the thing that makes signals really sing. But it's still just signals, and the same behaviour can always be replicated using manually nested atomic signals. EDIT: I've just realised you're OP, so you probably know more about your reactivity system than I do! But at least the way you're describing it, it sounds like it's working the same way as signals do, just with an emphasis on the nested signal case by default.
- vanviegen 1y ago
  That's indeed how Aberdeen works, except that the nested proxy objects are created on-demand, when first accessed. 'Nested signals' it is then. :-)

MrJohz 1y ago

Aberdeen's proxy is essentially an object of nested signals. In general: proxy({ name: "Foo", email: "bar", }); is semantically equivalent to new Signal({ name: new Signal("Foo"), email: new Signal("bar"), }); The syntax for getting a value will look different in each case, but using Javascript proxies you can fairly easily wrap the latter in such a way that it looks like the former. That's what happens with SolidJS's createStore utility, and I assume it's what's happening here as well. Aberdeen looks like it's taking Vue's approach of making the proxy/automatically nested case the default, which is typically more convenient as nested reactivity is the thing that makes signals really sing. But it's still just signals, and the same behaviour can always be replicated using manually nested atomic signals. EDIT: I've just realised you're OP, so you probably know more about your reactivity system than I do! But at least the way you're describing it, it sounds like it's working the same way as signals do, just with an emphasis on the nested signal case by default.

vanviegen 1y ago
That's indeed how Aberdeen works, except that the nested proxy objects are created on-demand, when first accessed. 'Nested signals' it is then. :-)