consider route segment default values

[UncleClapton]

This ticket is for dumping my ideas on default parameters for route segments.

Possible solutions

Default parameters object

.add('profile', '/profile/[tab]', { tab: 'overview' })

This approach would be the easiest to implement and adopt, but not exactly the clearest syntax to grok without having to consult documentation. This further increases onboarding costs in established projects.

I'm not overly concerned with that drawback, however. just something I would like to avoid in our own projects.

Extending route string syntax

.add('profile', '/profile/[tab=overview]')

This would be doable, but I don't know if this is the direction this library should go.

The big upside here is that it would be easily usable by people who do not alias/pre-define routes. I myself have been considering an approach where we just hold route strings in an enum object and refer to them that way. This would cater to that.

There are some MAJOR downsides to consider, though. First this breaks the strict relationship of route/href and the pages directory. This also would add considerable complexity to route compiler. It would need to reform the href string after stripping out our custom syntax. This could get costly.

Exporting predefined function to wrap a route

import { withDefaultParams } from '@fuelrats/next-named-routes/util'

/* stuff */

.add('profile', withDefaultParams('/profile/[tab]', { tab: 'overview' }))

Well this solves our readability issue. Now it's really clear what the intention is here. This could also open the door for other modifier functions down the line. Could be a cool system.

This idea works through taking advantage of what the internal Route class does when you pass it a function. When you give a string to Route, it first determines if the route is dynamic. If it is, a compiler function for that route is generated and assigned to the class property compile. When you pass in a function, however, that function will take the place of the compiler instead. we can utilize this to do something like:

function withDefaultParams (route, defaultParams) {
  const compile = getRouteCompiler(route) // internal conversion function generator
  
  return (params) => {
    return compile({
      ...defaultParams,
      ...params,
    })
  }
}

Adopting this pattern would open the door for a lot more features revolving around manipulating props. It can even be used directly with <Link /> as is:

const routes = {
  profile: withDefaultParams('/profile/[tab]', { tab: 'overview' }),
}

/* Later on in render() */

<Link route={routes.profile} />

The only problem I see is that while this works within the workflow of our own website, this may be a foreign idea to someone looking for a more straightforward approach.