Bump react-router-dom from 6.2.1 to 6.4.2 in /frontend

[dependabot]

Bumps react-router-dom from 6.2.1 to 6.4.2.

Release notes

Sourced from react-router-dom's releases.

[email protected]

Patch Changes

• fix: remove internal router singleton (#9227)

  This change removes the internal module-level routerSingleton we create and maintain inside our data routers since it was causing a number of headaches for non-simple use cases:

  • Unit tests are a pain because you need to find a way to reset the singleton in-between tests
    • Use use a _resetModuleScope singleton for our tests
    • ...but this isn't exposed to users who may want to do their own tests around our router
  • The JSX children <Route> objects cause non-intuitive behavior based on idiomatic react expectations
    • Conditional runtime <Route>'s won't get picked up
    • Adding new <Route>'s during local dev won't get picked up during HMR
    • Using external state in your elements doesn't work as one might expect (see #9225)

  Instead, we are going to lift the singleton out into user-land, so that they create the router singleton and manage it outside the react tree - which is what react 18 is encouraging with useSyncExternalStore anyways! This also means that since users create the router - there's no longer any difference in the rendering aspect for memory/browser/hash routers (which only impacts router/history creation) - so we can get rid of those and trim to a simple RouterProvider

  // Before
  function App() {
    <DataBrowserRouter>
      <Route path="/" element={<Layout />}>
        <Route index element={<Home />}>
      </Route>
    <DataBrowserRouter>
  }
  // After
  let router = createBrowserRouter([{
  path: "/",
  element: <Layout />,
  children: [{
  index: true,
  element: <Home />,
  }]
  }]);
  function App() {
  return <RouterProvider router={router} />
  }

  If folks still prefer the JSX notation, they can leverage createRoutesFromElements (aliased from createRoutesFromChildren since they are not "children" in this usage):

  let routes = createRoutesFromElements(
    <Route path="/" element={<Layout />}>
      <Route index element={<Home />}>
    </Route>
  );

... (truncated)

Changelog

Sourced from react-router-dom's changelog.

6.4.2

Patch Changes

• Respect basename in useFormAction (#9352)
• Enhance console error messages for invalid usage of data router hooks (#9311)
• If an index route has children, it will result in a runtime error. We have strengthened our RouteObject/RouteProps types to surface the error in TypeScript. (#9366)
• Updated dependencies:
  • [email protected]
  • @remix-run/[email protected]

6.4.1

Patch Changes

• Updated dependencies:
  • [email protected]
  • @remix-run/[email protected]

6.4.0

Whoa this is a big one! 6.4.0 brings all the data loading and mutation APIs over from Remix. Here's a quick high level overview, but it's recommended you go check out the docs, especially the feature overview and the [tutorial][rr-tutorial].

New APIs

• Create your router with createMemoryRouter/createBrowserRouter/createHashRouter
• Render your router with <RouterProvider>
• Load data with a Route loader and mutate with a Route action
• Handle errors with Route errorElement
• Submit data with the new <Form> component
• Perform in-page data loads and mutations with useFetcher()
• Defer non-critical data with defer and Await
• Manage scroll position with <ScrollRestoration>

New Features

• Perform path-relative navigations with <Link relative="path"> (#9160)

Bug Fixes

• Path resolution is now trailing slash agnostic (#8861)
• useLocation returns the scoped location inside a <Routes location> component (#9094)
• respect the <Link replace> prop if it is defined (#8779)

Updated Dependencies

• [email protected]

... (truncated)

Commits

• 92425b8 chore: Update version for release
• 1317087 chore: Update version for release (pre) (#9395)
• 5905109 chore: Update version for release (pre) (#9380)
• 540f94b fix: Strengthen route typings (#9366)
• 434003d fix: respect basename in useFormAction (#9352)
• 779d4af fix: update matchPath to avoid false positives on dash-separated segments (#9...
• d8e6d7f docs: add better docs and console errors for data router features (#9311)
• d405320 chore: update versions for release
• c4a27f7 chore: Update version for release (pre) (#9316)
• aeceb7d fix changeset config + update changelogs
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[BobanL]

This is currently not working because in Prompt we use the navigate block from the library and that is not intended for use. In this last version (6.4.x) they decided to remove that functionality entirely. They have decided not to add it for now.
Our options are:

• Use a new workaround to get block working: https://gist.github.com/MarksCode/64e438c82b0b2a1161e01c88ca0d0355
• Downgrade to react router v5 (Still maintained)
• Store unsaved changes in local storage and pull those up.

[emyl3]

This is currently not working because in Prompt we use the navigate block from the library and that is not intended for use. In this last version (6.4.x) they decided to remove that functionality entirely. They have decided not to add it for now. Our options are:

• Use a new workaround to get block working: https://gist.github.com/MarksCode/64e438c82b0b2a1161e01c88ca0d0355
• Downgrade to react router v5 (Still maintained)
• Store unsaved changes in local storage and pull those up.

Thank you for your research and digging into this, Boban! While testing locally I did see the problem you described. In regards to your options:

I was checking when and why we updated to v6 in the first place and it looks like it was to get to React 18: #3261 but based on the comment you linked Boban it looks like they support v5 for React 18 remix-run/react-router#8139 (comment) 🤔
Based on Nick's PR to upgrade to v6 though, it looks like a bunch of work was done to get v6 working so I am worried undo-ing that would also be a big effort if we downgrade to v5 (which leads me to lean towards your first option 👀)

[fzhao99]

It seems that we're using Prompt to block user navigation away from the PersonForm, FacilityForm, and UserDetail forms when they have unsaved data, which the maintainers call out specifically as a somewhat jarring UX pattern with a suggested replacement. Worth chatting with design about it, but I think their argument makes sense from a UX improvement perspective. The smoothest interaction in those forms would be just to persist / reload the unsaved data users input in the event they navigate away from an unsaved form.

I could be wrong since I haven't interacted with those browser API's in an SR context before, but storing unsaved formed data in local/sessionStorage just in these three forms shouldn't that be that big of a technical lift? Should be as simple as storing the form input as a json against the url as a key and then reloading if it exists on renavigation to the page. cc: @kenieh

Another consideration is whether we have any security issues persisting unsaved form data in session storage. It's technically PII, but since we're never persisting it in any data stores / it's only relevant in cases of unsaved form data, I'd hazard it's ok to handle it this way, but might be wrong here. cc: @rin-skylight

Assuming that's true, if we're getting the UX benefits on top of moving away from a dependency, that's worth it in my mind. Worth bringing up to the rest of the team, but I'd go with Boban's third suggestion after digging a little. cc: @emmastephenson

[georgehager]

I think for a version bump PR, we shouldn't introduce any behavior changes. It is worth design considering if we should change the user experience, however I think it's out of scope for this kind of PR. I think we should either 1) implement the suggested workaround for now keeping the existing behavior and have design decide if/when to prioritize a change in the future or 2) decide not to bump the version right now and close this PR, and again design can decide if/when they want to make this change down the road.

cc: @emmastephenson

[emmastephenson]

+1 to Elisa's comment about not wanting to downgrade to React Router v5 - it was a pretty big pain to upgrade in the first place as I recall, doesn't seem worth undoing just for this Prompt functionality.

I definitely lean towards the suggested solution of moving away from Prompt entirely, but agree with @georgehager that it's out of scope for this PR. I created a new ticket for design to address (#4534), and in the meantime I think we should just close this PR - implementing the workaround doesn't seem like a good use of dev time if we decide to turn around and change the design.

[dependabot]

OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting @dependabot ignore this major version or @dependabot ignore this minor version. You can also ignore all major, minor, or patch releases for a dependency by adding an ignore condition with the desired update_types to your config file.

If you change your mind, just re-open this PR and I'll resolve any conflicts on it.

[kenieh]

Is this something we could discuss at our next G&E sync? I'm not sure I'm following this thread

[kenieh]

Sounds like there isn't an immediate need for a design solution?

[georgehager]

@kenieh Emma added a new ticket (#4534 ) so I think prioritization can be discussed at next sync!

[georgehager]

But yeah, no urgent need until then!