Cross-virtual dom signals

[ealmloff]

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]

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]

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]

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]

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)

[tdomhan]

Is there currently any workaround for using signals across multiple windows?

[rydb]

Is there currently any workaround for using signals across multiple windows?

you could keep mutations to your data behind functions on newtype holders and have the value inside a rwlock

struct DioxusValue<T> {
    value: Arc<RwLock<T>>,
}

[tdomhan]

fwiw, I'm successfully using signals across multiple windows created via leak_with_caller, which works in my case as all signals live for the entirety of my application.