Prompt component in v6

[gustaff-weldon]

We are migrating big project to v6.
We just noticed this in migration guides:

is not currently supported
from v5 (along with usePrompt and useBlocker from the v6 betas) are not included in the current released version of v6. We decided we'd rather ship with what we have than take even more time to nail down a feature that isn't fully baked. We will absolutely be working on adding this back in to v6 at some point in the near future, but not for our first stable release of 6.x.

The latest version is 6.10 and Prompt is still missing.

We are relying on old Prompt in multiple scenarios where we do not want users to loose their work due to navigation.

What are the plans for the Prompt in v6?

[brophdawg11]

If you read through the thread in #8139 you'll see a bunch of explanations as to why we think blocking navigation is not always the best UX, but there were a few legitimate scenarios that we added unstable_useBlocker and unstable_usePrompt in 6.7.0 which can be used when using RouterProvider. It would be fairly simple to wrap your own Prompt component around the hook if needed. I would also advise you to avoid prompting via window.confirm if possible because it's impossible to do it 100% correctly with the browser APIs the way they are. You can provide a much more stable API with a custom UI around useBlocker, or an even better UI with auto-saving and re-populating of user-entered information.

• Release notes: https://github.com/remix-run/react-router/releases/tag/react-router%406.7.0
• Example usage of useBlocker: https://github.com/remix-run/react-router/tree/main/examples/navigation-blocking
• usePrompt PR: Add unstable_usePrompt #9932

[gustaff-weldon]

We only implemented this for the new Data Routers because the underlying implementation they leverage (and order of operation for routing versus updating window.history) makes it less error-prone. Consider it a new feature of data routers just like loaders, actions, and fetchers.

We need none of these data-related capabilities, but we need eg. useMatches which does not work with standard routers :)

It's not just fetchers - the data routers (like Remix) are built on top of the Web Fetch API. Every navigation creates a Request (just like a normal click on a <a> tag does - that's exctlty what you are preventing when you call e.preventDefault!).

It is exactly that Request that is failing, are you saying it is not only used for data concerns but also for regular navigation?

For testing purposes - you will need to polyfill the fetch API in your test environment. Here's how we do it for our own tests: https://github.com/remix-run/react-router/blob/main/packages/react-router/__tests__/setup.ts

Thanks, in the meantime I have found an issue #10375 where it was also mentioned :)
Since we do not use data loaders, I was thinking of just stubbing the objects, but if you use Request for anything else than data, this might not work, right...

if (!globalThis.fetch) {
  globalThis.fetch = () => {
    throw new Error('Fetch Unavailable');
  };

  const Request = function Request() {};
  const Response = function Response() {};

  globalThis.Request = Request;
  globalThis.Response = Response;
}

My concern is now, if we are in any danger when using data loaders without relying on data? Meaning, are there any assumptions that might cause us troubles/bugs because we will never pass any loaders, actions or fetchers.

[gustaff-weldon]

I might have jinxed it: #10166 (comment)

[brophdawg11]

are you saying it is not only used for data concerns but also for regular navigation

This is how it works today, yes. As soon as we receive a navigation event we construct the Request that was prevented - this is before we identify and run any matched loaders. In theory, it might be possible to delay creating a Request until we find a loader to run - but I'm not sure why this is an issue since Request is readily available in the browser and there's no real overhead to polyfilling it correctly during unit tests.

I would not recommend stubbing it as our implementation is built upon the assumption of a spec-compliant implementation so I would expect potential issues if you try to stub a half-baked Request.

if we are in any danger when using data loaders without relying on data

Within the Router, there shouldn't be. For migration purposes we expect all of the same behavior from components/hooks in BrowserRouter as in RouterProvider. The linked default error element discussion is the one exception I'm aware of since that changes behavior outside the router. We'll keep that proposal open so it can be reviewed during sone of the roadmap plannings.

[gustaff-weldon]

Within the Router, there shouldn't be. For migration purposes we expect all of the same behavior from components/hooks in BrowserRouter as in RouterProvider.

Interestingly, it looks there's a difference in behaviour when it comes to interacting with browser location in BrowserRouter and createBrowserRouter. It seems the BrowserRouter does sync url updates, whereas the createBrowserRouter (due to its data loaders approach) uses promises and updates the url in an async way.

We had a code that was updating url (originally withhistory.push, after migration with navigate) and when multiple components on the same page were adding params to url they were overriding each other with data router (worked fine with the BrowserRouter)

I think we solved this 🤞 with useSearchParams, but that was unexpected.

[brophdawg11]

yeah with both BrowserRouter and RouterProvider, you don't want to be navigating externally via history and always want to use the RR APIs (Link, navigate, setSearchParams).

There is a slight order of operations change with RouterProvider where we update window.history after updating navigational state (which is async to support loaders). In BrowserRouter``window.history was updated first and then react state immediately after. But as long as you use the RR APIs (useLocation instead of window.location) you shouldn't have issues.