search

DioxusLabs / dioxus

Fullstack app framework for web, desktop, mobile, and more.
https://dioxuslabs.com
Apache License 2.0
20.15k stars 772 forks source link

Cross-virtual dom signals #1569

Open ealmloff opened 10 months ago

ealmloff commented 10 months ago

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

esimkowitz commented 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!

ealmloff commented 10 months ago

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

esimkowitz commented 10 months ago

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?

ealmloff commented 10 months ago

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)