Reactivity lost on $state from class when said $state is consumed in another project (micro-frontend)

[webJose]

Ok, so I have wasted my entire work day trying to figure this one out.

I have class A that exposes the value field, which is $state. An instance of said class is created in the same module that defines the class and exported as a named export.

This named export is imported by a component that makes changes to the properties of the object stored in A.value, which is state. An $inspect() statement in another component in the same Svelte project triggers in accordance with these changes.

Now we jump the project barrier using single-spa. The same named export mentioned earlier is exported from another file, just to keep things separate. This other file is an entry point that becomes a "utility module" for other micro-frontends. It is the same named instance mentioned before.

This "utility module" is then imported from another Svelte project. The import is successful, but setting an $inspect reveals that reactivity did not make it to this other Svelte project.

My question, probably for core maintainers, is why. But maybe that's too difficult of a question with the information provided.

So let me tell you that logging the imported named object to the console shows that the object is of the expected class, and logging the value property reveals the value is a proxy object.

Is there anything in Svelte's internals that may preclude reactivity in the second project? Because I spent one whole day trying to figure this one out and could not. Maybe it's undocumented stuff?

[webJose]

@paoloricciuti, @dummdidumm Is reactivity of $state tied to a global collection of any kind that is unique per project/compilation, so that a "foreign" $state (state coming from an external Svelte project) would be "dead" in the context of another project/compilation?

[webJose]

I made this repository that replicates the problem using one root MFE and one child MFE. Follow the instructions in the README file to get it up and running.

[kwangure]

I hope I understand your problem. Disregard otherwise. From a cursory look at the linked repository and your description of the problem, it looks like you're hoping your state remains reactive across multiple instances of Svelte. Signal auto-tracking/subscriptions works is via shared variables/context.

For example in svelte/src/internal/client/runtime.js you'll see things like this:

/** @type {null | Effect} */
export let current_effect = null;

/** @param {null | Effect} effect */
export function set_current_effect(effect) {
	current_effect = effect;
}

That current_effect is used by the layers of effects to build a reactivity graph. If you have separate installations of Svelte, they end up as separate graphs where one is not aware of the other. For example, the more gnarly version of your problem is when a library accidentally packages version of Svelte as a dependency (instead of a peerDependency) and you can't tell why it's not reactive. The easiest way I can think of to sync nested micro-applications is using a query param and watching for url changes. I don't know if other Signal folks like the SolidJS community have other patterns that might be helpful.

PS: See this quick read by Ryan Carniato that might help you build a mental model of how Signals share context and reactivity graphs are constructed.

[webJose]

Thanks for dropping by. Your information is very helpful indeed. I opened an issue here as well, and dumdidumm pretty much stated this much, stating that the Svelte runtime needs de-duplication.

I have since updated the repository and have added the JP/SvelteExternalized branch where I think I managed to de-duplicate Svelte as one would de-duplicate other runtimes, such as React. The problem remained, however.

If you're interested, see #13234 for a bit more information.