4Catalyzer / found

Extensible route-based routing for React applications
https://4catalyzer.github.io/found/
MIT License
794 stars 55 forks source link

[Feature] Typed routes #1053

Open eMerzh opened 1 year ago

eMerzh commented 1 year ago

Hello,

i know it's a long stretch, but i was dreaming about beeing able to do routing to named route (i know the existing side plugin) but fully typed, like you couldn't route to an unexisting route verrifiied by typescript. I know there are other router doing this and i was wondering if it could be possible :)

Thanks a lot for your work:)

jquense commented 1 year ago

Yeah I'd like to have this at some point but I'm not convinced it makes sense as part of the route config. We've been experimenting with something similar at my work and while it's really nice to generate urls from routes you immediately run into cyclical import issues, that don't necessarily cause problems but are still frustrating to deal with.

In terms of limiting found APIs to only accepting valid routes, you run into similar problems and ultimately the user needs to override some core type themselves to pass in valid routes, since hooks wouldn't really be aware of the route config without introducing even more spots for cycles.

"Other" routers I've seen try this, tend to overstate their type safety, they tend to not actually be much safer than the spa-routing library in the end. Overall yes I'd like to make improvements or recommendations here but not confident yet on the right way

steinybot commented 7 months ago

We have been using https://github.com/japgolly/scalajs-react/blob/master/doc/ROUTER.md which is a Scala.js library. Of course that is in Scala but it is fully type safe. I'm trying to switch to found-relay with the TS -> Scala.js type conversions and this is one of the things that I am missing (the other big ones are that the Component is Component?: React.ComponentType<any>; rather than having nicely typed props, and the other is that match.location.state doesn't make use of TState so it is any).

I am able to workaround most of it by creating my own inverted tree of configuration objects which point to their parent (so they can generate their route location) and then use these to generate the route configuration.

To get the added type safety in hooks you can't have a single context. You would have to create a new context when creating the router. I'm not sure if this would be worth it.

If the hooks took an extra type parameter for the route config used this would be a big win even if it was unsafe. You would only run afoul if you had multiple routers and specified the wrong type. Even then it's no worse than providing a location that doesn't match.