Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clearing react-router errors requires an extra interaction #5687

Open
Rheeseyb opened this issue May 15, 2024 · 0 comments
Open

Clearing react-router errors requires an extra interaction #5687

Rheeseyb opened this issue May 15, 2024 · 0 comments
Labels
Perceived Bug Something that feels broken or like a problem

Comments

@Rheeseyb
Copy link
Contributor

Rheeseyb commented May 15, 2024

With the removal of the console proxy, and the restoration of the react-router specific error handling (for clearing the canvas after an internal error boundary is triggered) in #5682, the canvas now requires an extra interaction (e.g. scrolling or making another change to the code file, or even saving the code file) before the canvas reset is actually applied (check the video linked in that PR).

After a short investigation I narrowed this down to being caused by the way we update the mount count at the very end of the dispatch (via a mutation)

if (filesChanged.length > 0) {
finalStoreV1Final.unpatchedEditor = reactRouterErrorTriggeredReset(
finalStoreV1Final.unpatchedEditor,
reactRouterErrorPreviouslyLogged,
)
}
, and learned the following things:

  • Updating the mount count by clicking the reset canvas button in the toolbar still correctly causes the canvas to re-render
  • If we update both the patched and unpatched editor states with the new mount count in the above code then the error boundary persists even after further interactions
  • The mount count is definitely updated after the error is shown, but the updated value isn't read when pickUiJsxCanvasProps is called (hence why the canvas doesn't actually reset)
@maltenuhn maltenuhn added the Perceived Bug Something that feels broken or like a problem label May 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Perceived Bug Something that feels broken or like a problem
Projects
None yet
Development

No branches or pull requests

2 participants