Routing developer experience improvements: File-system based routing?

[platosha]

We are exploring the ideas on how to improve defining routes in Hilla applications.

For this discussion, let us focus on Hilla React applications that currently use @react/router, although, I think, most challenges here apply to Hilla Lit applications as well.

The Challenges

Let me share some known challenges related with navigation and routing.

Ergonomics of creating application views

Perhaps the most prominent challenge is that creating a new application view involves many steps with changes in four places:

1. creating the view component
2. adding a route
3. adding a menu link
4. updating the Java security configuration

Our previous take on this brought a ton of boilerplate code in the routes.tsx file in the Hilla application starters. Most of the complexity in this file was added for creating the menu links the using shared metadata. We decided that having this feature is not worth the boilerplate, so it is being removed. It was not a complete solution anyway, as we did not address the Java security configuration part.

Using URL parameters in views

Views that use URL parameters and dynamic segments, for example, /user/:id. Such parameter names need to be declared in both the routes and the view.

TypeScript does not help here to catch the name mismatches between the route map and the view code, as useParams() and such does not provide the name definitions.

Efficient data loading

When the route displays several components at the same time that require fetching the same data, it takes some extra care to avoid duplicate requests.

It gets even more complex if the application predicts the next navigation and eagerly preloads the data for it.

Decentralised route maps

Some developers might prefer extracting the routes to separate files, for example, if a centralised map becomes too big.

An ultimate case of a decentralised map is when the route and the view component are in the same file.

While this is probably possible with existing tools, we lack patterns and examples to follow.

Loading server pages

Applications are not always single-page (SPA), for some of them loading a page is required. For instance, when modernising a JSP application view-by-view, the new SPA views and old server pages should coexist for a while.

Multidimensional navigation

Some applications involve showing several router outlets at the same time, each with their own navigation context, similar to browser windows but on the same page. For example, imagine a multi-document interface (MDI) web application, where the user can open and edit several documents.

Solution proposal: file-system based routing

We do not have a single clear answer for all the challenges. One thing is relatively clear though: we don't blur the line between Java backend and TypeScript frontend, and require frontend developers to declare routes in Java.

Considering all the above, the best idea on our minds is introducing some file-system routing conventions similar to Next.js. This could help to improve the ergonomics a lot.

To illustrate this idea in short, for example creating the file frontend/views/hello/view.tsx with a React view component:

export default function HelloView() {
  return <div>Hello</div>;
}

...would produce a route for /hello => <HelloView/> in the route map with all the necessary configuration. Then, optionally, some metadata about the view could be added in a separate file, for example: frontend/views/hello/meta.ts.

Open questions

Some questions for your feedback:

• Can you relate to the challenges above? What makes the most impact for your team and application? Any other routing and navigation challenges to add?
• What do you think about file-system based routing in Hilla? Would that be a good fit for your work?
• Do you have any other related routing enhancement ideas? Feel free to share them.

[sveinnetnordic]

Will this solution solve routing for a Vaadin React/Flow hybrid app?

[Legioth]

That's an ortogonal issue. The main thing for hybrids is to integrate with the routing functionality in Flow. That can be done with any routing approach but it still needs to be implemented separately from the routing approach itself.