[feature] Investigate running MobX on top of signals standard / polyfill
mweststrate opened this issue · comments
We've been engaging with the initial draft of Signals. Time to actually verify we can run MobX on top of it! And provide feedback to the committee before it is at stage 3.
I am not completely comfortable with node (atom/signal) being coupled with value. When I did some experiments implementing observable structures, I concluded it's better to synchronize value access with actual nodes stored elsewhere, instead of changing shape of the underlying structure by replacing values with signals and (un)wrapping the signal at every possible occassion. You don't have to worry about descriptor value (signal) not matching the user facing value, you can delegate operations to native iterators, Reflect.<op>, etc.
If you want to support up-ahead subscriptions for not yet defined fields, you can't store signals to the properties/entries directly anyway.
Also I think not every node should need to maintain it's own set of options - eg. the equals check may be performed at the level of the structure, instead of every individual node.
It's interesting the proposal provides an example, which actually uses the synchronized access approach:
examples of nested reactive structures created with both Signals and Proxies: signal-utils
It seems to invalidate the signal by setting it to null, which I think wouldn't work with current proposal without also providing equals options. Alternatively one could store a version or duplicate the value. All of these are potentially wasteful.
I am not even sure if one should be forced to model the signal as a reference to an object. I think I would be more in favor of static functions acting upon some opaque node references. Eg. using string IDs could prove more helpful when considering SSR/Hydration/Resumability/persistency/workers/anything requiring serializability.