feat: upgrade react-router-dom

[0xdef1cafe]

taking over original PR from #695 to manage merge conflicts and get deployed internally

Description

Upgrade React Router

close #675

Ref

• https://typescript.tv/react/upgrade-to-react-router-v6/
• https://reactrouter.com/docs/en/v6/upgrading/v5#upgrade-to-react-router-v6

Notice

Before submitting a pull request, please make sure you have answered the following:

• Have you followed the guidelines in our Contributing guide?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?
• [] Do all new and existing tests pass? Does the linter pass?

Pull Request Type

• 🐛 Bug fix (Non-breaking Change: Fixes an issue)
• 🛠️ Chore (Non-breaking Change: Doc updates, pkg upgrades, typos, etc..)
• 💅 New Feature (Breaking/Non-breaking Change)

Issue (if applicable)

If applicable, please link to the github issue and put closes #XXXX in your comment to auto-close the issue that your PR fixes.

Testing

Please outline all testing steps

1. Pull branch locally and run yarn to install new deps
2. etc...

Screenshots (if applicable)

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Pages

Latest commit:	97eb23a
Status:	✅  Deploy successful!
Preview URL:	https://4c768492.web-29e.pages.dev

View logs

[0xdef1cafe]

@cjthompson this compiles and builds but shits the bed at runtime - see the cloudflare link. could you take another look please?

[cjthompson]

We cannot do this upgrade. react-router-dom v6 removes the ability to use nested routers. We use multiple <MemoryRouter>s within the default <BrowserRouter>.

We will need to revamp completely how we do routing. This also means that we may have to rethink how we do routing for plugins. We may have to have plugins export all of their routes to work with v6 (or choose another router module?).

[gomesalexandre]

We cannot do this upgrade. react-router-dom v6 removes the ability to use nested routers. We use multiple <MemoryRouter>s within the default <BrowserRouter>.

We will need to revamp completely how we do routing. This also means that we may have to rethink how we do routing for plugins. We may have to have plugins export all of their routes to work with v6 (or choose another router module?).

What's the rationale to using MemoryRouter as a nested router? If it is to have "independent" (or rather reusable) subrouters, isn't it possible to use e.g The ${path}/relative syntax where path would be either somePath (nested route) or '' (independent route)?. MemoryRouters should be for contexts that don't have access to the browser (history) API, typically Node tests.

I think by keeping the nested routers nested, but not making them memory routers anymore, we would be able to upgrade. Not sure about the plugin implications here.

[cjthompson]

We cannot do this upgrade. react-router-dom v6 removes the ability to use nested routers. We use multiple <MemoryRouter>s within the default <BrowserRouter>.
We will need to revamp completely how we do routing. This also means that we may have to rethink how we do routing for plugins. We may have to have plugins export all of their routes to work with v6 (or choose another router module?).

What's the rationale to using MemoryRouter as a nested router? If it is to have "independent" (or rather reusable) subrouters, isn't it possible to use e.g The ${path}/relative syntax where path would be either somePath (nested route) or '' (independent route)?. MemoryRouters should be for contexts that don't have access to the browser (history) API, typically Node tests.

I think by keeping the nested routers nested, but not making them memory routers anymore, we would be able to upgrade. Not sure about the plugin implications here.

My point is only that the way we are doing routing will require more work to change before we can upgrade and those changes were not known when the ticket was written and were not in scope of the ticket.

[gomesalexandre]

My point is only that the way we are doing routing will require more work to change before we can upgrade and those changes were not known when the ticket was written and were not in scope of the ticket.

Oh, precisely. There is no way to implement this at 0 cost by just bumping react-router and adapting to the breaking changes, that's right!