Share Reactivity between multiple instances of Solid

[CreativeTechGuy]

TLDR Question:

Is there a way to "export" reactivity (eg: a signal, a context accessor, etc) from one instance of Solid to "import" into another running on the same page?

Background/Context:

We are looking at rewriting a big application with 40+ devs all working on one codebase into a collection of isolated teams which can deliver bits of the page (as web components) in isolation. We are looking to use Solid for both the shell and the web component fragments. Each one will be build by a different team, bundled separately, and composed at runtime. As a result, there'll be several copies of Solid on the page. But to the user they should all look and feel like one application. So, for example, they should all share a single Solid Router. To make that work, the shell app would need a way to pass around the signal which gets the current params for example. For "passing", we are just setting a global variable and reading it from the other app. This doesn't work. (Seemingly due to separate Symbols?) More generally, we would hope to have a solution to be able to pass around any reactive thing like generic signals to another instance of Solid and have it preserve reactivity.

I know that one solution would be to have all of the apps share one instance of Solid at runtime, but to enable the teams to be independent and not be all locked to a single Solid version, we'd like to decouple them as much as possible.

[samuelstroschein]

Do you have to bundle each fragment/compenent individually?

If not, using peer SolidJS as a peer dependency should work. That said, we are also interested in sharing reactivity between multiple Solid instances (opral/inlang#1122). Not relying on a peer dependency would be great.

[CreativeTechGuy]

Unfortunately we do have to bundle separately since the teams need to be independent. If they all had to lock on one shared version of Solid (or any other libraries) then it'd be a real pain to update as every team would need to synchronize their deployments and upgrades at exactly the same time. That most likely would result in very infrequent updates. So since teams will likely drift on different versions and different teams will update their packages at different times, having them be separate is ideal.

Also peer dependencies unfortunately wouldn't work since each component is built as a web component, distributed to a separate CDN and then loaded on one site at runtime. So at no point would one team directly depend on an npm package from another team, to again reduce coupling points. We could do a module federation thing where we all share one copy of the library at runtime, but that is back to the top problem where we'd all have to lock on the same version.

I totally get this is an unusual set of requirements and most people wouldn't benefit from this. But I'd be surprised if there wasn't some escape hatch already built in which could be used for this.

[CreativeTechGuy]

I'm marking this as an answer, albeit a partial answer. But hopefully it's helpful to others nonetheless.

You can "export" a signal using observable and "import" using from

---

Code sample

Summary: Create a signal in one app, turn it into an observable, then pass that observable to another solidjs app instance, that second solid app would turn the observable back into a signal.

// Source app
import { createSignal, observable } from "solid-js";

const [number, setNumber] = createSignal(1);
setInterval(() => {
    setNumber(Math.random());
}, 100);
window.signalObservable = observable(number);

// Destination app
import { from } from "solid-js";

// This now mirrors the `number` signal in the other app and will update like any other signal would in this app
const number = from(window.signalObservable);

Caveat: The reason I say this is a partial solution is this approach doesn't work for Context as the context provider won't be in the same Solid component tree. So not a generic solution, but for raw signals it works great.