Open ealmloff opened 10 months ago
I've been thinking about this too as a way to even further signal-ify #1443
I would be interested in helping work on this!
This doesn't seem too difficult to implement. We need to change from the context API here to a unsync::OnceCell in a thread local
Would thread local be enough for multi window support? I can see how that would help with multi-vdom, but it seems to me like a separate shared thread would be needed to manage signals between windows
Update: oh are you thinking more in how to separate the ownership from the context, not for how to communicate signals between windows?
Would thread local be enough for multi window support? I can see how that would help with multi-vdom, but it seems to me like a separate shared thread would be needed to manage signals between windows
Update: oh are you thinking more in how to separate the ownership from the context, not for how to communicate signals between windows?
I think it would be enough for multi-window support for signal effects and allocation, currently I believe we have desktop set up so all windows live on the same thread.
Subscriptions will not work because scope ids are not unique across multiple virtual doms. Subtrees will fix subscriptions for multi-window apps. (I think we could technically make this work today with schedule_update
instead of schedule_update_any
, but storing a trait object for every scope a signal subscribes to seems excessive)
Specific Demand
Signals currently use the context API to communicate with eachother. This works great within one virtual dom, but once you create a new virtual dom it can cause issues. For example, you cannot create a signal in one window and send it to another window in this example
Implement Suggestion
We could switch from the context API to a global lazy static/oncecell runtime