Hacker News new | ask | show | jobs
by fernandorojo 1557 days ago
Those kinds of implementation details won't be hard to add to Solito. The API I'm using is that of Next.js. If they adapt to suspenseful approaches to routing, Solito will too.

There are also experiments in the works to make React Navigation lazy load code with suspense on the Native side by bringing Webpack to Native: https://github.com/EvanBacon/expo-auto-navigation-webpack

Another added bonus of this approach is that it will have a pages/ folder API like Next.js.

I don't see why Solito won't be able to support these use-cases as they arise.
1 comments
Benjamin_Dobell 1557 days ago
That's fair, you're limited by the technologies you're using. I guess that's a problem with these sorts of libraries, you can find yourself being "the lowest common denominator". Of course, your library is very useful, and there are plenty of apps that I imagine can just drop in Solito. So this isn't at all to detract from its real-world value today.

However, as much as it's convenient to get up and running (with bundle splitting), the file-system based router is in my opinion probably the weakest part of Next.js. It would be top priority on my list of things to go. The main issue is it's fundamentally not type safe.

For example, Solito's useParams() is fragile because refactoring can easily cause param substitution to come out of sync with param consumption (in another component). My most recent solution (not in Next.js) for this is:

  const {partnerId} = useRouteParams(routes.tails.partner);
That's 100% type-checked. Creating a URL for that route is also type checked and done like:

  routes.tails.partner({partnerId: "blah"});
I'd really like to see routing libraries adopt type safe practices.

EDIT: I suppose the file-system based routing could be kept if you pair it with code generation. Maybe that's an option?

link