Несколько параллельных маршрутов с маршрутом 404 в React Router

Question

Вот пример работающей маршрутизации в моем приложении, где:

• <AuthProvider /> используется в нескольких местах внутри <AuthRoute /> компонентов.
• <AuthRoute /> - это просто обёртка вокруг <Route /> компонента, который делает логи c, связанные с аутентификацией пользователя

...
<Router history={history}>
  <AuthProvider>
    <Switch>
    <Route path='/' exact component={HomePage} />
    <AuthRoute path='/account' exact component={MyAccount} />
    ...
    <Route path='*' exact component={NotFound} />
    </Switch>
  </AuthProvider>
</Router>
...

Теперь, когда мне больше не нравятся простые красивые рабочие приложения, я представил что-то для пользователей, чтобы использовать токены. Поэтому в обновленной версии параллельная маршрутизация представлена ​​следующим образом:

...
<Router history={history}>
  <TokenProvider>
    <Switch>
      <TokenRoute path='/blabla' exact component={TokenizedStuff} />
    </Switch>
  </TokenProvider>

  <AuthProvider>
    <Switch>
      <Route path='/' exact component={HomePage} />
      <AuthRoute path='/account' exact component={MyAccount} />
      ...
      <Route path='*' exact component={NotFound} />
    </Switch>
  </AuthProvider>
</Router>
...

Проблема При посещении маршрута /blabla отображается <TokenizedStuff />, а также <NotFound />.

Я подумал, что это может быть из-за того, что есть два нижних уровня <Switch />, поэтому я поднял их следующим образом:

...
<Router history={history}>
  <Switch>
    <TokenProvider>
      <TokenRoute path='/blabla' exact component={TokenizedStuff} />
    </TokenProvider>

    <AuthProvider>
      <Route path='/' exact component={HomePage} />
      <AuthRoute path='/account' exact component={MyAccount} />
      ...
      <Route path='*' exact component={NotFound} />
    </AuthProvider>
  </Switch>
</Router>
...

Это теперь исправило вышеуказанную проблему, но создало еще одну проблему . Типичный!

Теперь посещение /account маршрута ничего не делает. Изучив React devTools, я обнаружил, что оно разбирает дерево компонентов на <TokenProvider /> и останавливается там.

Я мог бы объединить маршруты в один файл маршрутизации и обернуть его несколькими провайдерами, чтобы проверить работу и работу это, но я бы предпочел держать его в чистоте и читаемом для других членов команды сейчас и присоединиться в будущем.

Буду очень признателен за помощь.

Answer 1

Похоже, что вы сможете достичь того, что вы используете, используя вложенные маршруты :

Псевдо-пример, как описано в комментариях:

<Router history={history}>
  <Switch>
    <Route path='/token' exact={false} component={TokenProvider} />
    <Route path='/' exact={false} component={AuthProvider} />
  </Switch>
</Router>

Маршруты верхнего уровня задают точку ветвления более высокого уровня для вашего приложения, тогда вы можете иметь дополнительные логики маршрутизации c в дочерних компонентах. С помощью этой техники можно разработать несколько решений.

Я считаю, что это более масштабируемый способ управления маршрутами в более крупных приложениях, чем использование одного постоянно растущего routes компонента.

В этом посте в блоге содержится хорошее резюме и разъясняются некоторые полезные практики (например, использование match.path для создания дочерних маршрутов).

Answer 2

Вот то, к чему я наконец пришел:

...
<Router history={history}>
  <TokenProvider>
    <AuthProvider>
      <Switch>
      <Route path='/' exact component={HomePage} />
      <AuthRoute path='/account' exact component={MyAccount} />
      <TokenRoute path='/blabla' exact component={TokenizedStuff} />
      ...
      <Route path='*' exact component={NotFound} />
      </Switch>
    </AuthProvider>
  </TokenProvider>
</Router>
...

Где TokenRoute заботится обо всех токенизированных вещах и AuthRoute заботится всего материала, основанного на аутентификации . Лучшее, что я нашел таким образом, было то, что эта конкретная обработка вступит в действие только тогда, когда будет найден конкретный маршрут, в противном случае он игнорируется.

Данный подход Оливера также является еще одним хорошим способом разделения проблем, но это было сложно. реализовать в существующем крупномасштабном приложении. Это было бы хорошей отправной точкой для любого маленького / нового приложения.