I don't know.. Imagine you have a react component that needs to interact with something written in svelte...
I'm not convinced that people are building integration APIs for consumption by external code. That means no JS events (redundant since it uses stores or signals and whatnot) and minimal callback availability to hook into a component state.
One might not control the code if this is from an open-source library for instance.
Maybe the premise is "don't do that" , but then people still wanted WebComponents at some point. So seems there exist use-cases for component interaction. Or were people mistaken in the first place?
I own both sides of the stack. Say I have a react component that happens to mount a svelte component in the DOM.
I expect Svelte code to be running somewhere (I wanted to use a svelte component, I have to initialize that stack).
I expect React code to be running somewhere (The main page is react, for example).
I expect to have some sort of signaling or state management solution (say a redux store, since the main page is react).
I can just update the redux store from both stacks. The store emits the correct events whenever it's updated - all subscribers are notified - react-redux does its magic and conditionally re-renders my react tree based on the new state.
I can do exactly the same thing in Svelte - subscribe to store events, see an events when react changes something, update my svelte app in response.
---
And it's absolutely not limited to redux... I can do the same thing by hand with global state, or by emitting custom events in the DOM, or any of a hundred other ways to get these two apps to work together. I own both sides - making them play nice is normally trivial (if not always quick, and sometimes tedious as all get out).
I guess my response is: "So make it visible". Because that's easy to do with any manner of methods.
Sure - each library is going to do its own thing with regards to how it manages it's internal DOM and state, but that does not matter at all.
All you care about in wiring them together is:
"Can I call some js code in response to state change in svelte?"
and
"Can I call some js code in response to a state change in react?"
and the answer to both is a resounding "Yes!".
So now I can easily make the state of one visible to the other... I just run some code in response to a change on either side that updates the state of the other - done.
If you want to get adventurous - you can automate the entire thing away with a proxy store, so it happens everywhere by default.
> I don't know.. Imagine you have a react component that needs to interact with something written in svelte...
this doesn't happen in practice... like at all...
is your implicit assumption that anything written in react will automatically work just fine with svelte but not the other way around? why would react -> svelte be any easier than svelte -> react, and why is the burden on React to solve interoperability problems between competing frontend frameworks?
I'm not convinced that people are building integration APIs for consumption by external code. That means no JS events (redundant since it uses stores or signals and whatnot) and minimal callback availability to hook into a component state.
One might not control the code if this is from an open-source library for instance.
Maybe the premise is "don't do that" , but then people still wanted WebComponents at some point. So seems there exist use-cases for component interaction. Or were people mistaken in the first place?