The react-router project is the go-to library for client-side route management for React (and React Native). It is easy to use, well maintained, and solves the vast majority of routing needs for the vast majority of react projects (big ups to Michael Jackson, Ryan Florence, and all the great community members). It’s likely even more powerful and featureful than you may realize. For example, on their documentation for their Route component’s path property, there’s a deceivingly simple statement that a path’s value can be “Any valid URL path or array of paths that path-to-regexp@^1.7.0 understands.” The examples provided then show relatively simple use cases for path. However, if you read through the docs for path-to-regexp, you’ll find out how much you get from this for robust, validated, parameterized routes. Below I’ll give just a few simple examples that I make heavy use of on most projects using react-router.
Example 1: Optional parameters via ?
The react-router docs provide an example for a parameterized route. Below is an updated version of it demonstrating the optional parameter qualifier (?): In this example, we’ve made the URL parameter optional and provided a default value. This technique is especially handy when you build a page/component with a “default” view and additional views that show based on user interactions or selections. You could also handle these cases via child routes, but sometimes an optional URL parameter is a better fit. Occasionally you may even use both!Example 2: Simple constrained/validated params (enums)
Optional parameters are handy, and you can do more to parameterize your URLs further. As its name suggests, path-to-regexp constructs regular expressions based on your path strings to determine matches and handle path parameterization. The construction process includes applying regular expressions to constrain/validate your URL params themselves! A simple example I rely on frequently is a set of possible exact matches. This example is handy whenever you have enums or some other finite-state domain of valid values for your view(s)’ state, data fetching parameterization, or both. Here’s a different updated version of the URL params example with this enum-style path constraint applied: In the example, I’ve updated the route’s path as:"/:id(netflix|zillow-group|yahoo|modus-create)"This path means that only the exact values listed will count as valid IDs; anything else will not count as a match for this route. You can demonstrate this by selecting the invalid id link or changing the running app’s URL to an invalid value. I frequently make use of these kinds of routes in production to drive property selectors for fields in a larger complex data object (something like “/entityView/:subEntity(propertyA|propertyB”) or for actual enumerated values, such as those defined in a Mongoose Schema.Example 3: More advanced example
As I mentioned above, in the end, these constraints on path matching bottom out in regular expressions, which means you can construct pretty beefy matching rules based on your application’s business domain. Here’s a small taste of a simplified but realistic route scenario, similar to code I have used in production: Let’s go over the main pieces here. First, there’s a simple “home” route, “/” . Next, there’s the example route:"/:id([a-f\d]{24}|new)"This route constrains :id to being 1 of two things, either a valid MongoDB ObjectID value (case-insensitive hex string that is exactly 24 digits long) or the exact value “new“. If a URL doesn’t match one of those two things, the URL will not match the path. Since this is the only “real” path/route, any other case results in a URL match not found and falls to the “No match” route, “*”. The “No match” route will <Redirect/> to /, which will again match the “home” route. As with the previous example, you can demonstrate this by selecting the invalid id link or changing the running app’s URL to an invalid value. In the real world, this is the sort of thing that React developers would use to load an Edit Form and populate the form via fetched data by ID from an API. You could even use this technique to set some sensible defaults for the “new” case. Note that we ensure only valid MongoDB IDs match, so we’re gating the issue in the URL’s id param. This rule runs whether someone copy/pastes the URL or navigates to it using the application controls.