-
Notifications
You must be signed in to change notification settings - Fork 58
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
Scopes #187
Comments
This is definitely worth considering! It would be a bit more flexible and less magical to be able to have multiple signal graphs rather than one global state. On the other hand, it would seriously harm any hope of interop for frameworks to be using different signal graphs without shared autotracking, so this capability could easily turn into a footgun. If we did have multiple graphs, we might need to come up with a compelling story for how you're supposed to intentionally bridge between two signal graphs if you want to use them in concert. (That's not necessarily a bad thing -- I think system boundaries like Watcher are where the current proposal is weakest, and having the boundary APIs be up to the task of stitching two separate signal graphs together seamlessly after the fact would be proof of a sort that the boundary APIs were sufficiently expressive.) I think in Incremental the corresponding concept would be the Solid's idea of multiple roots isn't really in the same space; Solid keeps only one global state, and any source you read (regardless of what root it was created in) can be autotracked by any memo or effect. |
I didn't see this when I made the comment, but I just realized the long framework hypothetical in the third paragraph in #195 (comment) is alerting to encapsulation issues in the current design that (in part) requires much of this very thing to solve. I approached it from a different angle, but ultimately, it boils down to a need for scoping, just for consistency across watcher composition. |
We have a need for something like scopes, and I'm not sure how we'd be able to implement it without them We have a scenario where we an application uses signals for its internal state, as well as exposes some of them to an external user. However, it's important for the application to control the timing of when signals get updated - it is a 3D application that needs to update its internal state during a frame, and only allow the external user to react to updates after the frame update The way I would do it with scopes is:
MobX has the ability to isolate global state, so this feature can also be important in order for the existing libraries to start using the native signals internally Additionally, due to the API's ability to return signals contained in watchers and computeds via |
Right now, all the signals share the same hidden state and are apart of the same reactivity system.
I was wondering why this shouldn't be made explicit, to control the hidden state, and group together sub-graphs #159 , to possibly allow for different reactive algorithms, bulk deallocation/garbage collection, better dev tools, and labeling of the reactive graph, or maybe things like Relays?
I'm not a JS expert. But maybe this could look like:
It's just an idea. Let me know what you think.
Prior Art
OCaml Incremental Scopes
Leptos Runtimes
SolidJS Root
The text was updated successfully, but these errors were encountered: