Generate static values for dynamic params

[akamfoad]

Dynamic params are a powerful way to render content based on dynamic URL segments, in React Router you can make a segment of the URL dynamic by adding a colon in front of the segment,

For example in /transactions/:transactionId/details

• /transactions is a static segment, only matches exact same characters
• /:transactionId is a dynamic segment, it matches anything
• /details is a static segment, only matches exact same characters

so with that structure the route can match for following URLs:

• /transactions/3737-hd78-2uhw7/details
• /transactions/sg7s-3uh7w-sjus7/details
• /transactions/s7s2-s7hvq-olax/details

Which is amazing, because you can use the params.transactionId from the Component, loaders and actions to fetch different data that has the same structure.

But often, you have pages, that are dynamic but constrained, meaning, the page should only be shown when the dynamic segment is one of some values, not any values.

For example, you have a page to show a list of user onboardings, you want separate pages for UX purposes with same UI and structure, but their data will be different based on the status of these onboardings, for example we have "pending" | "approved" | "rejected" statuses.

In this instance, I'd make my route as /onboardings/:status

and in my loader, action or Component, you'd have to use something like zod to validate the params.status, and if it doesn't match, throw a 404 response:

const statusSchema = z.enum(["pending", "approved", "rejected"])

export const loader = async ({ params }: RouteType)=>{
  const { status: statusParam } = params
          // ^ string

  const parsedStatus =  statusSchema.safeParse(statusParam)

  if(!parsedStatus.success) throw new Response(undefined, {status: 404})

  const { status } = parsedStatus

  // whatever else you do with your loader
}

This is fine, but when you need this in other places like action or Component, or other data functions, especially when you have many routes like this, you realize an abstraction on RR side will make this much easier.

The approach I have in mind:

Generate possible values

A function generateStaticParams returns an object where each property is a dynamic segment name from current route and the value is an array of strings that can be narrowed down to a set of values for typing purposes:

// it can be any string, but also it can be a const, for example `["pending", "approved", "rejected"] as const`
type GenerateStaticParams<T extends string> = Record<
  Partial<keyof Route.Params>,
  T[]
>;

export const generateStaticParams = () => {
  return {
    status: ["pending", "approved", "rejected"] as const,
  };
};

If a key is left out from the returned object, it'll have its initial type which is string or string | undefined

Pros

1. Easy & Straightforward
2. Generate Strongly typed params automatically
3. Can be statically optimized at build time

Note

This is similar but different to pre-rendering and its purely for the business logic purposes as a convenience and type safety feature

There is also another approach that is mutually exclusive to the generateStaticParams, let's call this one validateDynamicParams, this one receives the dynamic params of current route and returns a boolean indicating whether the URL with those dynamic params should match current route or not, effectively typing the params but this one runs on per-navigation basis, which might make a slight delay but effctively centeralizes the typing and validation of the dynamic params.

[woble]

Ideally it should be part of the the route definition (somehow) seeing how RR7 already generates types from that. But does it really give you anything if you still must validate (something that should not be part of RR) the provided information to avoid runtime errors?

route('contacts', 'contacts.route.tsx', [
  route(':id(number)', 'contact.route.tsx', [
    route(':status(enum:pending|approved|rejected', 'contact-status.routes.tsx'),
  ])
])

[akamfoad]

Too much magic, one of the things that might turn even more people to Remix v3 or RRv7 would be going back to where you can define routes in a simple manner.

Going away from magic and providing good docs would be the thing that boosts more people to use this amazing product.

At least that is me and my team's experience!

[sergiodxa]

My first approach would be to define multiple routes per param value

export default [
  route("transactions/pending/details", "file.tsx"),
  route("transactions/approved/details", "file.tsx"),
  route("transactions/rejected/details", "file.tsx"),
]

But you can't re-use a file, it would be nice if we could pass params to the file path

export default [
  route("transactions/pending/details", "file.tsx?status=pending"),
  route("transactions/approved/details", "file.tsx?status=approved"),
  route("transactions/rejected/details", "file.tsx?status=rejected"),
]

Then RR could pass status param to those routes using the value on the file path, more similar to how .htaccess works

[woble]

You should be able to reuse files by defining an explicit ID in route options.

[akamfoad]

I don't think this would scale well for dynamic params with numerous enumerated values, imagine having a dozen possible values!

I personally prefer a new export such as generateStaticParams than something like this approach, I think people ultimately get tired of these hidden magical ways that feels more like an escape hatch than a feature.

[sergiodxa]

@woble even if you can define possible ids, you can't set a param, so the route would have to manually parse the pathname to extract the param (it could be as simple as using url.pathname.includes("pending" tho), instead of using params.status.

@akamfoad If you have too many dynamic values you should be checking in the loader, this can be useful for scenarios where you just have a few possible value, specially because a function will make people want to get this list more dynamically (like from a DB or API).

A new export will add way more complexity to the compiler as now it needs to also check if a route has this export to generate the possible static values.

[akamfoad]

I agree it adds more complexity, I personally see the values, as I mentioned though its a convenient feature, not something critical, we've been able to manage without it, but it could simplify the the route module a lot in scenarios like mentioned imo.

[woble]

@akamfoad

How do you envision generateStaticParams being defined across ancestor and descendant routes?

For example both route users/:id as well as sub-route users/:id/apps would have to define the same generateStaticParams because both routes share the same id. Introducing another sub-route, for example users/:id/apps/:appId would need to do the same with addition to appId.

So unless this can be done in a way where it does not need to be repeated, it isn't any different than the current approach of writing schemas and validating params in loader/action or their client equivalents. Unless of course I am missing something from your explanation.

[akamfoad]

As I mentioned each route will get their own dynamic parms only, for example /users/:id only can generate the static params for ID if needed and users/:id/apps/:appId route will only generates the static params for appId.

if a route defines multiple params, it can generate static params for all of them, those values that aren't in the current route dynamic params would be ignored, for example:

// `/users/:userId/:accountType/transactions/:transactionType/`

export const generateStaticParams = ()=>{
  return {
    accountType: ["PERSONAL", "BUSINESS"],
    transactionType: ["incoming", "outgoing"]
  }
}

Here we generate values for accountType and transactionType because the route is responsible for both, since its a leaf route, also note userId is left out, so it'll stay dynamic and match any value.

but if they're different routes, they will each define their own params like:

// `/users/:userId/:accountType`

export const generateStaticParams = ()=>{
  return {
    accountType: ["PERSONAL", "BUSINESS"],
  }
}

// `/users/:userId/:accountType/transactions/:transactionType/`

export const generateStaticParams = ()=>{
  return {
    transactionType: ["incoming", "outgoing"]
  }
}