Never attach ping listeners in legacy Suspense

[acdlite]

I noticed a weird branch where we attach a ping listener even in legacy mode. It's weird because this shouldn't be necessary. Fallbacks always synchronously commit in legacy mode, so pings never happen. (A "ping" is when a suspended promise resolves before the fallback has committed.)

It took me a moment to remember why this case exists, but it's related to React.lazy.

There's a special case where we suspend while reconciling the children of a Suspense boundary's inner Offscreen wrapper fiber. This happens when a React.lazy component is a direct child of a Suspense boundary.

Suspense boundaries are implemented as multiple fibers, but they are a single conceptual unit. The legacy mode behavior where we pretend the suspended fiber committed as null won't work, because in this case the "suspended" fiber is the inner Offscreen wrapper.

Because the contents of the boundary haven't started rendering yet (i.e. nothing in the tree has partially rendered) we can switch to the regular, concurrent mode behavior: mark the boundary with ShouldCapture and enter the unwind phase.

However, even though we're switching to the concurrent mode behavior, we don't need to attach a ping listener. So I refactored the logic so that it doesn't escape back into the regular path.

It's not really a big deal that we attach an unnecessary ping listener, since this case is so unusual. The motivation is not performance related — it's to make the logic clearer, because I'm about to add another case where we trigger a Suspense boundary without attaching a ping listener.

To confirm we have coverage for this branch, I commented it out and ran the test suite. The relevant tests are in ReactLazy-test.js.

I suggest reviewing without whitespace changes: https://github.com/facebook/react/pull/22407/files?diff=split&w=1

[acdlite]

This is the special branch that I moved. The rest of the diff is updating comments that referred to outdated implementation details.

[sizebot]

Comparing: d174d06...5cedfd2

Critical size changes

Includes critical production bundles, as well as any change greater than 2%:

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
oss-stable/react-dom/cjs/react-dom.production.min.js	+0.02%	129.52 kB	129.54 kB	+0.02%	41.28 kB	41.29 kB
oss-experimental/react-dom/cjs/react-dom.production.min.js	+0.02%	132.34 kB	132.37 kB	+0.01%	42.22 kB	42.23 kB
facebook-www/ReactDOM-prod.classic.js	+0.02%	411.10 kB	411.19 kB	+0.01%	76.08 kB	76.09 kB
facebook-www/ReactDOM-prod.modern.js	+0.02%	399.67 kB	399.75 kB	+0.01%	74.37 kB	74.38 kB
facebook-www/ReactDOMForked-prod.classic.js	+0.02%	411.10 kB	411.19 kB	+0.01%	76.09 kB	76.09 kB

Significant size changes

Includes any change greater than 0.2%:

(No significant changes)

Generated by 🚫 dangerJS against 5cedfd2

[salazarm]

So it seems the only place where we do something for the ShouldCapture flag is here: https://github.com/facebook/react/blob/main/packages/react-reconciler/src/ReactFiberUnwindWork.new.js#L64

So am I right in understanding that your change is just signaling that we haven't done the work for this fiber yet and that this flag is only used for attributing time spent doing work to it?

[acdlite]

The profiler call is a red herring. The relevant part of this branch is that it marks a DidCapture flag:

react/packages/react-reconciler/src/ReactFiberUnwindWork.new.js

Line 117 in d174d06

workInProgress.flags = (flags & ~ShouldCapture) | DidCapture;

and it returns the work-in-progress fiber (which in this case is a Suspense boundary) instead of returning null:

react/packages/react-reconciler/src/ReactFiberUnwindWork.new.js

Lines 125 to 127 in d174d06

	return workInProgress;
	}
	return null;

That will tell the work loop to render the Suspense boundary again:

react/packages/react-reconciler/src/ReactFiberWorkLoop.new.js

Lines 1700 to 1708 in d174d06

	if (next !== null) {
	// If completing this work spawned new work, do that next. We'll come
	// back here again.
	// Since we're restarting, remove anything that is not a host effect
	// from the effect tag.
	next.flags &= HostEffectMask;
	workInProgress = next;
	return;
	}

And since we set a DidCapture flag, we'll render the fallback this time instead of the regular children:

react/packages/react-reconciler/src/ReactFiberBeginWork.new.js

Line 1936 in d174d06

const didSuspend = (workInProgress.flags & DidCapture) !== NoFlags;

[acdlite]

If you look at the old code, though, we were already doing this because line 315 here causes us to fall through to the regular concurrent mode path:

react/packages/react-reconciler/src/ReactFiberThrow.new.js

Lines 313 to 316 in d174d06

	if (
	(workInProgress.mode & ConcurrentMode) === NoMode &&
	workInProgress !== returnFiber
	) {

which looks like this:

react/packages/react-reconciler/src/ReactFiberThrow.new.js

Lines 412 to 414 in d174d06

	attachPingListener(root, wakeable, rootRenderLanes);
	workInProgress.flags |= ShouldCapture;

So the net change for the branch I added is:

- attachPingListener(root, wakeable, rootRenderLanes);
workInProgress.flags |= ShouldCapture;

[salazarm]

Ahh okay makes sense!

[salazarm]

Thanks for the thorough explanation looks good