Implications of using multiple routers across app
Hi, I was wondering, given certain patterns, where for example you may have a webapp with lots of view/kind of like windows. And without really digging into how routers specifically works in detail. Whether it would be possible to have just multiple routers across the app, kind of spread on the app or index component. Like a way to kind of organize the views in a decoupled way.
I tried it, and seems to work, but wonder if anyone has any ideas or knowledge about anything to look out for, or any opinion about it.
Thanks
5 Replies
as a related but slightly different question, the example on the website at https://docs.solidjs.com/solid-router/concepts/layouts shows that to use layouts you can pass a component to the root prop of layout. Is there much difference between this and rendering the Router as a child of Layout?
vs
There is an open PR for parallel routes.
It needs to be noted however that for the last 2 years the role of routers has started to shift away from simple “view organizers” to “core orchestrators of client side, non-ephemeral state”.
If this trend persists, distinct roles for diffetrent types of routers may emerge. Ideally there should only be one single router orchestrating the various aspects of client side state, though there may be room to delegate some responsibilities to sub-routers.
GitHub
Build software better, together
GitHub is where people build software. More than 100 million people use GitHub to discover, fork, and contribute to over 420 million projects.
okay nice, thank you.
It's strange that when I tested it, seemed to work fine, so wonder what the PR addresses, I think I'd have to look into in with more detail. Interesting comment about the role of routers, I'll think about that. I think if I had to chose right now I would say I don't agree so much with that shfit, although I see the convenience. I guess you mention that as a general trend, nothing about solid in specific right?
While simmering for a while in the background the idea got mainstream attention with When to Fetch.
The impact on
solid-router
(via SolidStart) emerged here.
The recent kerfuffle with React 19 is evidence though that a significant segment of developers isn't ready to shift from “fetch-on-render” to “render-as-you-fetch” even when from the UX perspective it's the right thing to do.Real World React
YouTube
When To Fetch: Remixing React Router - Ryan Florence
Recorded live at Reactathon 2022. Learn more at https://reactathon.com
When To Fetch: Remixing React Router
We've learned that fetching in components is the quickest way to the worst UX. But it's not just the UX that suffers, the developer experience of fetching in components creates a lot of incidental complexity too: data fetching, data muta...
React 19 and Suspense - A Drama in 3 Acts
React 19 is a very promising release - but there's something not quite right yet with suspense...
Amazing, thanks for the details, lots of intersting stuff here