Allow multiple blockers instance

[ingro]

Hi there!

I was trying to use the new unstable_useBlocker hook to prevent users to navigate away when a form is in "dirty" state, using the example provided in the examples/navigation-blocking folder.

Everything worked fine until I tried a page with 2 distinct forms. Here the blockers work correctly only if both have the same state. If only one form is dirty and I click on any link to navigate away from the page I get a strange behavior: at first it keeps me on the page (without showing the confirm dialog) but if I click again it navigates away to the new destination.

Checking in the source code I see that it's not a bug but a deliberate choice.

// useBlocker() is a singleton for now since we don't have any compelling use
// cases for multi-blocker yet
let blockerKey = "blocker-singleton";

// ...

let blocker = router.getBlocker(blockerKey, blockerFunction);

// Cleanup on unmount
React.useEffect(() => () => router.deleteBlocker(blockerKey), [router]);

Do you think that this is a valid use case to have multiple blockers? I think this can easily be achieved with an optional second argument to the useBlocker function, thus allowing to pass a custom key and keeping the singleton key as default.

Hope this makes sense, my english is not very good :/

[brophdawg11]

Unfortunately, it's not quite as simple as providing a key for the blocker. The semantics around blocking are already tricky to get right since we're fighting the browser APIs most of the way. Managing multiple blockers that may block/unblock/proceed independently is a bigger challenge that we're not sure is necessary at the moment. Navigations are global, and therefore when you block them the idea of being blocked is also global.

While your page might have 2 forms, you're still "blocking" based on a single concept - "is either form dirty". I would suggest lifting the useBlocker to a common parent component and using useBlocker(() => isForm1Dirty || isForm2Dirty)

[ingro]

Thanks for your reply @brophdawg11, I was not aware of all the challenges that multiple blockers would bring to the router.

I will try to lift the blocking process up in the tree as you suggested, although it will not be easy since the forms components manage their state internally.

[ivan-pik]

We had the same scenario: Two editable forms using the "unstable_usePrompt " hook.

I expected that when at least one hook is provided with the when condition being true it would stop the navigation regardless of the conditions of the other hooks.

We had to patch /node_modules/@remix-run/router/dist/router.js
to block navigation when some blocker is "blocking".

let entries = Array.from(blockerFunctions.entries());

let blockingKey: string | undefined = undefined;

entries.some(entry => {
    let [blockerKey, blockerFunction] = entry;
    let blocker = state.blockers.get(blockerKey);

    if (blocker && blocker.state === "proceeding") {
    // If the blocker is currently proceeding, we don't need to re-check
    // it and can let this navigation continue
       return;
    }

    // At this point, we know we're unblocked/blocked so we need to check the
    // user-provided blocker function
    if (blockerFunction({ currentLocation, nextLocation, historyAction })) {
      blockingKey = blockerKey;
      return blockerKey;
    }
})

return blockingKey

It really is not practical to lift the "touched" state to the parent, especially in a very large app.

It is hard to "force" developers to make sure there is only one hook used at any one time in the React tree.

What bad consequences would "if any hook requires navigation blocking, block it" caused?

@remix-run+router+1.3.2.patch.txt

[jaschaio]

I strongly support this as well. Not being able to use hooks multiple times is an anti pattern. Lifting state up doesn't work in complex applications (that expect hooks to be able to used multiple times).

The patch by @ivan-pik works

[ESoch]

Support a case for multiple useBlockers here as well. To provide a concrete example of a use case:

A micro-frontend implementation where there's a shared header (with header level navigation) and a micro-frontend with micro-frontend level navigation.

We'd want to block navigation if the user tries to navigate in either application (App Shell or Sub MFE) but it's not a simple matter to lift the userBlocker up into the application shell and still have reference to the forms.

[rmeschian]

Hi guys, I'm still getting: "A router only supports one blocker at a time". I appreciate the complexity of dealing with the browser's routing API, which is why I think it still makes sense to use a singleton pattern, but under the covers. The useBlocker should still be used multiple times by users. Their handlers can be put into a singleton list and called via an iterator. If any of them block, then the route is blocked. This is ivan-pik's solution I think. What are the drawbacks to this approach?

[jaschaio]

Works fine for me in production since Feb.

[jaschaio]

Just bumping this up as 8 months later I still find myself using @ivan-pik patch. Any reason why this is not merged? I created a PR for it: #10780

[nivnahmias]

Why hasn't this been resolved yet? it seems like a super simple fix

[CyanoFresh]

Need this feature!