Replies: 8 comments 2 replies
-
Unfortunately, it's not quite as simple as providing a 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 |
Beta Was this translation helpful? Give feedback.
-
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 We had to patch
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? |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
Support a case for multiple 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. |
Beta Was this translation helpful? Give feedback.
-
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? |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
Why hasn't this been resolved yet? it seems like a super simple fix |
Beta Was this translation helpful? Give feedback.
-
Need this feature! |
Beta Was this translation helpful? Give feedback.
-
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.
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 :/
Beta Was this translation helpful? Give feedback.
All reactions