Discussion about default routes about wouter

[omgovich]

Hi @cbbfcd. I just checked out the react-router docs/demos and found out that they use the same approach where order matters. So we probably shouldn't change anything in code.

[molefrog]

Hey guys! I think we should definitely implement support for default prop since a lot of people were asking about that and not everyone gets the :rest* trick — it's just not developer-friendly.

Should the order matter is a good question. Rather than copying it 1-1 from react-router I would first think about possible design choices we would need to make in both cases.

Let's say the order doesn't matter. Can the Switch then have multiple default routes? I think it can, it's valid, although not a very practical scenario. In this case which one gets rendered: first one, second or both?

On the other hand, we can just say that default Route is a Route that always matches in a Switch. In this case this:

<Switch>
  <Route default>foo!</Route>
  <Route path="/app">app</Route>
  <Route default>Second default!</Route>
</Switch>

Would always render foo! no matter what (even if the location is /app). And it fits better with the Switch contract "only one child is renderer at most at the time".

[molefrog]

To recap.
Position-independent default Route:
✔️Possible better DX, although breaks the common "catch-all" mental model from server-side routing
❓Isn't clear how it should behave in edge cases
❓Probably harder to implement and is size-consuming: will need to make an extra iteration over children to determine the first default route

Position-dependent default Route:
✔️Follows the same mental model used in RR and server-side routing (Rails, Express, Sinatra etc.)
✔️Doesn't break the Switch contract:
✔️Should be relatively easy to implement — add an extra check here:

-      (match = matcher(element.props.path, location || originalLocation))[0] 
+      (element.props.default || (match = matcher(element.props.path, location || originalLocation))[0] 

So, I would go with the latest. Let me know what you think!

[omgovich]

@molefrog I like the Position-dependent default Route option.
But I think that most of the users won't understand that default means.
Probably they're looking for 404 or fallback route.

Also I guess that we should keep in mind common practices that developers used to.
So I have two options to discuss.

1. Route without path

Instead of defining the new param, just use the same approach as react-router.

Routes without a path always match (react-router docs)

<Switch>
  <Route path="/">Home</Route>
  <Route path="/app">App</Route>
  <Route>404</Route>
</Switch>

-      (match = matcher(element.props.path, location || originalLocation))[0] 
+      (!element.props.path || (match = matcher(element.props.path, location || originalLocation))[0] 

2. Route with path="*"

This is the way to setup default route in vue-router.
And it works in react-router as well.
I guess this is the way that users expect.

<Switch>
  <Route path="/">Home</Route>
  <Route path="/app">App</Route>
  <Route path="*">404</Route>
</Switch>

We could just change this line:

-      (match = matcher(element.props.path, location || originalLocation))[0] 
+      (element.props.path === "*" || (match = matcher(element.props.path, location || originalLocation))[0] 

... or update the matcher.

[cbbfcd]

Hey guys! I think we should definitely implement support for default prop since a lot of people were asking about that and not everyone gets the :rest* trick — it's just not developer-friendly.

Should the order matter is a good question. Rather than copying it 1-1 from react-router I would first think about possible design choices we would need to make in both cases.

Let's say the order doesn't matter. Can the Switch then have multiple default routes? I think it can, it's valid, although not a very practical scenario. In this case which one gets rendered: first one, second or both?

On the other hand, we can just say that default Route is a Route that always matches in a Switch. In this case this:

<Switch>
  <Route default>foo!</Route>
  <Route path="/app">app</Route>
  <Route default>Second default!</Route>
</Switch>

Would always render foo! no matter what (even if the location is /app). And it fits better with the Switch contract "only one child is renderer at most at the time".

Yep! I just have this idea. I mentioned a related PR before, but I think I can have a better implementation.i will try

[cbbfcd]

@molefrog I like the Position-dependent default Route option.
But I think that most of the users won't understand that default means.
Probably they're looking for 404 or fallback route.

Also I guess that we should keep in mind common practices that developers used to.
So I have two options to discuss.

1. Route without path

Instead of defining the new param, just use the same approach as react-router.

Routes without a path always match (react-router docs)

<Switch>
  <Route path="/">Home</Route>
  <Route path="/app">App</Route>
  <Route>404</Route>
</Switch>

-      (match = matcher(element.props.path, location || originalLocation))[0] 
+      (!element.props.path || (match = matcher(element.props.path, location || originalLocation))[0] 

2. Route with path="*"

This is the way to setup default route in vue-router.
And it works in react-router as well.
I guess this is the way that users expect.

<Switch>
  <Route path="/">Home</Route>
  <Route path="/app">App</Route>
  <Route path="*">404</Route>
</Switch>

We could just change this line:

-      (match = matcher(element.props.path, location || originalLocation))[0] 
+      (element.props.path === "*" || (match = matcher(element.props.path, location || originalLocation))[0] 

... or update the matcher.

👍

[cbbfcd]

reach/router Breaking some routines, I think the effect is not bad.

[cbbfcd]

Matching the first one is accepted by most people. Following this pattern, Position-dependent may be better, but using /:any* is really confusing, I prefer default or evev no path attribute....

[molefrog]

Same here, position-dependent with no path sounds like an ideal option.

[cbbfcd]

i will make a PR later !!! 😂

[cbbfcd]

@molefrog @omgovich

in Route:

const [matches, params] = match || useRouteMatch;

so

(!element.props.path || (match = matcher(element.props.path, location || originalLocation))[0] 

if we don't have a path prop, the match will be 0，and this will cause a trouble.
if i fixed the problem with:

((match = [!element.props.path])[0] ||
(match = matcher(element.props.path, location || originalLocation))[0])

i can pass all the unit test, but the size limit(+10b), and i think this solution is ugly.
so, do you hava any suggestions?

[molefrog]

Would something like this work:

if (
  isValidElement(element) &&
  // 1. If `path` is present — match against it
  // 2. No `path` — use always positive match
  (match = element.props.path
    ? matcher(element.props.path, location || originalLocation)
    : [true, {}])[0]
)

[cbbfcd]

looks great! The main problem now is the size limit, let me think about it.

[molefrog]

@cbbfcd Hey, the feature has finally landed in the new release: https://github.com/molefrog/wouter/releases/tag/v2.5.0

Thanks again for your awesome work on the feature!