S
SolidJS6mo ago
Max

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
Max
MaxOP6mo ago
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?
render(
() => (
<Router root={Layout}>
<Route path="/" component={Home} />
<Route path="/hello-world" component={<div>Hello world!</div>} />

</Router>
),
document.getElementById("app")
);
render(
() => (
<Router root={Layout}>
<Route path="/" component={Home} />
<Route path="/hello-world" component={<div>Hello world!</div>} />

</Router>
),
document.getElementById("app")
);
vs
render(
() => (
<Layout>
<Router>
<Route path="/" component={Home} />
<Route path="/hello-world" component={<div>Hello world!</div>} />
</Router>
</Layout>
),
document.getElementById("app"),
);
render(
() => (
<Layout>
<Router>
<Route path="/" component={Home} />
<Route path="/hello-world" component={<div>Hello world!</div>} />
</Router>
</Layout>
),
document.getElementById("app"),
);
peerreynders
peerreynders6mo ago
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.
From An unknown user
From An unknown user
From An unknown user
Max
MaxOP6mo ago
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?
peerreynders
peerreynders6mo ago
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...
Max
MaxOP6mo ago
Amazing, thanks for the details, lots of intersting stuff here
Want results from more Discord servers?
Add your server