Infinite Error when React error boundary uses unrenderable MUI components
Hey all, I hope you're doing well. I'm running into an issue that's been confusing me related to React error boundary. Essentially, we've got an Error Boundary nested inside a MUI theme provider which uses a number of style overrides for MUI components. When an app is unable to load these components (the specific situation we're running into is when
Object.entries is unavailable due to a call in createStyled.js in @mui/system), the error boundary seems to kick in as expected. However, within that boundary, we are also using MUI components that are subject to this same problem.
I would expect that if a component within the boundary were to error in such a manner, it would simply exit the boundary and result in an uncaught error, breaking the client. However, what we're observing is that an infinite error occurs, wherein these components continue to try to render over and over again. Is the boundary catching its own error? I have a sandbox reproduction here. Please keep in mind it will break the tab - the way I've been able to observe the error is by selecting Open in New Window, copying the link, and then pasting this link into another tab with the developer console already open.
There are a few ways I could mitigate this (e.g. move the boundary outside of the ThemeProvider and style separately, polyfill Object.entries to deal with this specific situation, don't use MUI in the boundary), but I feel like this is something that should be solvable, and I was wondering if anyone can tell me the very obvious thing I'm doing wrong.
We are rendering client-side, no server rendering at all.
https://codesandbox.io/s/objective-dust-umpr1cedreeseg
CodeSandbox
objective-dust-umpr1c - CodeSandbox
objective-dust-umpr1c by edreeseg using @emotion/react, @emotion/styled, @mui/material, react, react-dom, react-error-boundary, react-scripts
1 Reply
UPDATE: This seems to be due to the Dialog component adding a portal. I don't know the exact mechanics, but adding a
disablePortal that will be passed to the DialogRoot (which is a styled Modal) seems to resolve this issue, if it suits your needs.