You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm trying to use this module in the context of micro-frontends (ie. a single page which composes independent widgets written in different frameworks), and I have run across compatibility issues.
In my research, I tried combining a svelte app using svelte-router with a react app using react-router. There are two main ways to do navigation in JS, which I'm analyzing separately:
The history API (pushState)
Because the history API doesn't provide a way to listen for changes, a workaround is always necessary. svelte-router and react-router use different and incompatible approaches to solve the problem:
svelte-router hooks the browser API so it can be notified when functions are called
You can't really argue which is best. Both are necessary evils. The problem is: they don't work together!
Because svelte hooks the browser API, it is able to receive state changes initiated in react.
However, when svelte makes changes to the URL, react doesn't see it because it doesn't use its shim.
The location API
If path navigation is not requirement and you can use hash navigation, then the location API is a suitable candidate.
The main advantage of the location API is that it has native support for listening.
Here, react-router is able to respond to hash changes initiated from outside React, presumably because it listens to the hashchange event.
But svelte-router does not use the location API at all. Even in hash navigation, svelte-router keeps using the troublesome history API. So this time communication from react to svelte doesn't work!
The table below summarizes the compatibility issues:
routing mode
React -> Svelte
Svelte -> React
path (history)
✅
🚫
hash (mixed)
🚫
✅
hash (location)
✅
✅
The last line is the suggested solution: For hash-based navigation, use only the location API. Because its support for listening is built-in, it will work out of the box!
The text was updated successfully, but these errors were encountered:
I'm trying to use this module in the context of micro-frontends (ie. a single page which composes independent widgets written in different frameworks), and I have run across compatibility issues.
In my research, I tried combining a svelte app using svelte-router with a react app using react-router. There are two main ways to do navigation in JS, which I'm analyzing separately:
The history API (pushState)
Because the history API doesn't provide a way to listen for changes, a workaround is always necessary. svelte-router and react-router use different and incompatible approaches to solve the problem:
You can't really argue which is best. Both are necessary evils. The problem is: they don't work together!
Because svelte hooks the browser API, it is able to receive state changes initiated in react.
However, when svelte makes changes to the URL, react doesn't see it because it doesn't use its shim.
The location API
If path navigation is not requirement and you can use hash navigation, then the location API is a suitable candidate.
The main advantage of the location API is that it has native support for listening.
Here, react-router is able to respond to hash changes initiated from outside React, presumably because it listens to the
hashchange
event.But svelte-router does not use the location API at all. Even in hash navigation, svelte-router keeps using the troublesome history API. So this time communication from react to svelte doesn't work!
The table below summarizes the compatibility issues:
The last line is the suggested solution: For hash-based navigation, use only the location API. Because its support for listening is built-in, it will work out of the box!
The text was updated successfully, but these errors were encountered: