Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

[feature] Investigate running MobX on top of signals standard / polyfill #3854

Open
mweststrate opened this issue Apr 4, 2024 · 1 comment
Labels
🍗 enhancement 🚧 experimental 🎁 mobx Issue or PR related to mobx package

Comments

@mweststrate
Copy link
Member

mweststrate commented Apr 4, 2024

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.

https://github.com/proposal-signals/proposal-signals

@mweststrate mweststrate changed the title [feature [feature] Investigate running MobX on top of signals standard / polyfill Apr 4, 2024
@mweststrate mweststrate pinned this issue Apr 4, 2024
@mweststrate mweststrate mentioned this issue Apr 4, 2024
17 tasks
@urugator
Copy link
Collaborator

urugator commented Apr 7, 2024

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

https://github.com/NullVoxPopuli/signal-utils/blob/642ec945000b672f9fc370b68dd9f5185ecd2422/src/object.ts#L33-L37

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.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
🍗 enhancement 🚧 experimental 🎁 mobx Issue or PR related to mobx package
Projects
None yet
Development

No branches or pull requests

2 participants