-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[feature] Investigate running MobX on top of signals standard / polyfill #3854
Comments
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, It's interesting the proposal provides an example, which actually uses the synchronized access approach:
It seems to invalidate the signal by setting it to 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. |
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
The text was updated successfully, but these errors were encountered: