Skip to content

Commit a06cd9e

Browse files
authored
[DevTools] Refactor Forcing Fallback / Error of Suspense / Error Boundaries (#30870)
First, this basically reverts 1f3892e to use a Map/Set to track what is forced to suspend/error again instead of flags on the Instance. The difference is that now the key in the Fiber itself instead of the ID. Critically this avoids the fiberToFiberInstance map to look up whether or not a Fiber should be forced to suspend when asked by the renderer. This also allows us to force suspend/error on filtered instances. It's a bit unclear what should happen when you try to Suspend or Error a child but its parent boundary is filtered. It was also inconsistent between Suspense and Error due to how they were implemented. I think conceptually you're trying to simulate what would happen if that Component errored or suspended so it would be misleading if we triggered a different boundary than would happen in real life. So I think we should trigger the nearest unfiltered Fiber, not the nearest Instance. The consequence of this however is that if this instance was filtered, there's no way to undo it without refreshing or removing the filter. This is an edge case though since it's unusual you'd filter these in the first place. It used to be that Suspense walked the store in the frontend and Error walked the Fibers in the backend. They also did this somewhat eagerly. This simplifies and unifies the model by passing the id of what you clicked in the frontend and then we walk the Fiber tree from there in the backend to lazily find the boundary. However I also eagerly walk the tree at first to find whether we have any Suspense or Error boundary parents at all so we can hide the buttons if not. This also implements it to work with VirtualInstances using #30865. I find the nearest Fiber Instance downwards filtered or otherwise. Then from its parent we find the nearest Error or Suspense boundary. That's because VirtualInstance will always have their inner Fiber as an Instance but they might not have their parent since it might be filtered. Which would potentially cause us to skip over a filtered parent Suspense boundary.
1 parent d72e477 commit a06cd9e

File tree

8 files changed

+170
-257
lines changed

8 files changed

+170
-257
lines changed

Diff for: packages/react-devtools-shared/src/__tests__/inspectedElement-test.js

+1-12
Original file line numberDiff line numberDiff line change
@@ -2975,16 +2975,12 @@ describe('InspectedElement', () => {
29752975
// Inspect <ErrorBoundary /> and see that we cannot toggle error state
29762976
// on error boundary itself
29772977
let inspectedElement = await inspect(0);
2978-
expect(inspectedElement.canToggleError).toBe(false);
2979-
expect(inspectedElement.targetErrorBoundaryID).toBe(null);
2978+
expect(inspectedElement.canToggleError).toBe(true);
29802979

29812980
// Inspect <Example />
29822981
inspectedElement = await inspect(1);
29832982
expect(inspectedElement.canToggleError).toBe(true);
29842983
expect(inspectedElement.isErrored).toBe(false);
2985-
expect(inspectedElement.targetErrorBoundaryID).toBe(
2986-
targetErrorBoundaryID,
2987-
);
29882984

29892985
// Suppress expected error and warning.
29902986
const consoleErrorMock = jest
@@ -3009,20 +3005,13 @@ describe('InspectedElement', () => {
30093005
inspectedElement = await inspect(0);
30103006
expect(inspectedElement.canToggleError).toBe(true);
30113007
expect(inspectedElement.isErrored).toBe(true);
3012-
// its error boundary ID is itself because it's caught the error
3013-
expect(inspectedElement.targetErrorBoundaryID).toBe(
3014-
targetErrorBoundaryID,
3015-
);
30163008

30173009
await toggleError(false);
30183010

30193011
// We can now inspect <Example /> with ability to toggle again
30203012
inspectedElement = await inspect(1);
30213013
expect(inspectedElement.canToggleError).toBe(true);
30223014
expect(inspectedElement.isErrored).toBe(false);
3023-
expect(inspectedElement.targetErrorBoundaryID).toBe(
3024-
targetErrorBoundaryID,
3025-
);
30263015
});
30273016
});
30283017

0 commit comments

Comments
 (0)