[Bug]: navigate with unstable_usePrompt, causing Invalid blocker state transition: unblocked -> proceeding error.

[woochanleee]

What version of React Router are you using?

6.8.0

Steps to Reproduce

I created a CodeSandbox playground, which you can access by following the steps below.

1. Click the "toggle" button
2. Click the "submit" button
3. error occurred

Screen.Recording.2023-05-12.at.6.19.31.PM.mov

Expected Behavior

No Invalid blocker state transition: unblocked -> proceeding error occurs, navigate works well.

Actual Behavior

Invalid blocker state transition: unblocked -> proceeding error occurs, navigate doesn't works.

ETC

In the linked code sandbox, wrap "navigate" in "setTimeout" seems to work.
But, i would like to know what the underlying solution is, and what caused the problem to occur.

[kertis15]

I am using useBlocker, and I have the same issue. Interesting is, that on version 6.11.2 it is working without error, but on version 6.14.0 is not.

[brophdawg11]

Does this slightly altered version of usePrompt fix your issues?

function usePrompt({ when, message }: { when: boolean; message: string }) {
  let blocker = useBlocker(when);

  React.useEffect(() => {
    if (blocker.state === "blocked") {
      let proceed = window.confirm(message);
      if (proceed) {
        blocker.proceed();
      } else {
        blocker.reset();
      }
    }
  }, [blocker, message]);

  React.useEffect(() => {
    if (blocker.state === "blocked" && !when) {
      blocker.reset();
    }
  }, [blocker, when]);
}

[brophdawg11]

OK - so on submit, after successfully saving the user data, you want to unblock and then navigate without showing window.confirm, right? I think the fix in #10687 will still show window.confirm even though the data has already been saved, so I'm not sure if that's the right fix for this specific use case or not.

In your case, I do think you want navigate to be in a setTimeout since you need the setIsOpen(false) to unblock the blocker prior to navigating, so it requires react to re-render to update the usePrompt.

[brophdawg11]

Actually a better approach may be to decouple the modal state/blocker state/submitted state. I think what you really want here is that we unblock and we navigate away upon successful submission of user data. Normally this would be done with saving to an action and redirecting, but in your setup I think your navigation is a side effect of the submission, not the click:

Here's an updated approach in https://codesandbox.io/s/hopeful-sky-psshcw?file=/src/index.js which allows React to update the blocker based on the isSubmitted state prior to navigating. It's essentially accomplishing the same thing as setTimeout but doing so via first-class React primitives and is likely more robust in concurrent mode updates and such.

[woochanleee]

OK - so on submit, after successfully saving the user data, you want to unblock and then navigate without showing window.confirm, right?

Yes !!! Excalty.

It's essentially accomplishing the same thing as setTimeout but doing so via first-class React primitives and is likely more robust in concurrent mode updates and such.

Oh, thanks for another solution.

but in your setup I think your navigation is a side effect of the submission, not the click:

I read sharing-logic-between-event-handlers in the React docs and wanted to navigate in the onSubmit handler instead of useEffect as described here.

[louis-young]

Here's an alternate solution that doesn't introduce a new state value or effect: https://codesandbox.io/s/react-router-useprompt-flushsync-mhq5jg

It uses the flushSyncAPI to force React to flush the pending state update immediately. I think both solutions are awesome, but I thought I'd throw this in the mix too 🙂

[woochanleee]

I already saw that in the thread below, i think that's a great solution too!

[louis-young]

Thanks for raising this issue. I ran into this yesterday.

I had a look at what was going on under the hood and reasoned about this with Matt. I've raised #10687 and explained the cause of the bug there 🙂

[brophdawg11]

I think that's a great solution as well! I guess what I'm getting at is - do we actually have a "bug" in usePrompt or are we just holding it wrong in these cases?

[brophdawg11]

(I want to keep the new unit tests regardless - they're great!)

[louis-young]

I think it'd be nice to not throw a somewhat obscure exception when somebody uses it in this way. It might not work in the way that they intended it to, but that's just down to React's functional model, closures, and when React processes state updates; people run into issues like this all the time with stale state values within a closure and I don't think it's anything new.

Alternatively, if we're confident that this is the only scenario in which this exception is thrown, then perhaps we throw a more human-friendly exception in this scenario.

I'm not convinced we should be throwing at all here, but what do you think?

[brophdawg11]

I think that's fair - if folks use it in this "incorrect" way (where the intention is to unblock but the navigation still blocks because the unblock + navigation happened synchronously) it would be better to let the block happen instead of throwing. That at least alerts the user to the underlying issue and they can then fix it with flushSync/isSubmitted/setTimeout/etc.

[louis-young]

I think so, that'd get my vote 👍

[brophdawg11]

Per the thread above, this was a bit of an add use-case and can be fixed with slight changes to the application logic. We did merge #10687 which will avoid the thrown exception - that should be released in 6.14.3 since we already started the release branch for 6.14.2 before this was merged.

But it's worth noting that this still does not behave as the original issue would have expected. Unblocking and navigating in the same event loop will still trigger the prompt after the fix. There are app-land solutions using flushSync/useState/setTimeout in the threads above.

[brophdawg11]

We just published version 6.15.0-pre.0 which involves this issue. If you'd like to take it for a test run please try it out and let us know what you think!

[leonpatry]

Hi I can confirm that with the latest released version 6.15 we still experienced the issue (in our case using useBlocker). The slightly altered version above (resetting blocker when blocker.state === "blocked" && !when) did fix the issue.

[av-k]

At version 6.23.1, I can confirm that this issue also can occurs when, between useBlocker has been called and the next call of blocker.proceed() the value in the nextLocation variable is changed. This can be due to the substitution of any URL query parameters, for example.

In my case the solution was to disable any URL manipulations during working with useBlocker logic.