Failed error boundaries are a special case of resuming work
When an error in thrown in the begin phase, we begin work on the error boundary a second time to unmount the children. This is a special case of "resuming" work that we need to account for. The children are set to the current children so that we can delete them.
Andrew Clark committed
Jun 19, 2017 at 16:24 UTC
5a32e89b3de383a9418e3e58068693eea1c022e0
1 file changed
+11
src/renderers/shared/fiber/ReactFiberBeginWork.js
+11
@@ -768,6 +768,17 @@ module.exports = function<T, P, I, TI, PI, C, CX, PL>(
768
// Add an error effect so we can handle the error during the commit phase
769
workInProgress.effectTag |= Err;
770
771
+ // This is a weird case where we do "resume" work — work that failed on
772
+ // our first attempt. Because we no longer have a notion of "progressed
773
+ // deletions," reset the child to the current child to make sure we delete
774
+ // it again. TODO: Find a better way to handle this, perhaps during a more
775
+ // general overhaul of error handling.
776
+ if (current === null) {
777
+ workInProgress.child = null;
778
+ } else if (workInProgress.child !== current.child) {
779
+ workInProgress.child = current.child;
780
+ }
781
+
782
if (
783
workInProgress.pendingWorkPriority === NoWork ||
784
workInProgress.pendingWorkPriority > priorityLevel