Skip to content

Commit b53ea6c

Browse files
authored
[Bugfix] Passive effects triggered by synchronous renders in a multi-root app (#17347)
* Regression test: Effects dropped across roots See #17066 * [Bugfix] Passive effects loop The bug ------- In a multi-root app, certain passive effects (`useEffect`) are never fired. See #17066. The underlying problem ---------------------- The implicit contract of `flushPassiveEffects` is that, right after calling it, there should be no pending passive effects. In the normal case, in concurrent mode, this is true. But the current implementation fails to account for the case where a passive effect schedules synchronous work, which in turn schedules additional passive effects. This led to `rootWithPendingPassiveEffects` being overwritten in the commit phase, because an assignment that assumed it was replacing null was actually replacing a reference to another root, which has the consequence of dropping passive effects on that root. The fix ------- The fix I've chosen here is, at the beginning of the commit phase, keep flushing passive effects in a loop until there are no more. This doesn't not change the "public" implementation of `flushPassiveEffects`, though it arguably should work this way, too. I say "public" because it's only used by implementation layers on top of React which we control: mainly, the legacy version of `act` that does not use the mock Scheduler build. So there's probably still a bug in that `act` implementation. I will address `act` in a follow-up. The ideal solution is to replace the legacy `act` with one implemented directly in the renderer, using a special testing-only build of React DOM. Since that requires a breaking change, we'll need an interim solution. We could make the "public" `act` recursively flush effects in a loop, as I've done for the commit phase. However, I think a better solution is to stop automatically flushing the synchronous update queue at the end of `flushPassiveEffects`, and instead require the caller to explicitly call `flushSyncUpdateQueue` (or the equivalent) if needed. This follows the same pattern we use internally in the work loop, which is designed to avoid factoring hazards like the one that resulted in this bug.
1 parent f4cc45c commit b53ea6c

File tree

2 files changed

+44
-2
lines changed

2 files changed

+44
-2
lines changed

packages/react-dom/src/__tests__/ReactDOMFiberAsync-test.internal.js

Lines changed: 35 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -9,7 +9,7 @@
99

1010
'use strict';
1111

12-
const React = require('react');
12+
let React;
1313
let ReactFeatureFlags = require('shared/ReactFeatureFlags');
1414

1515
let ReactDOM;
@@ -26,6 +26,7 @@ describe('ReactDOMFiberAsync', () => {
2626
beforeEach(() => {
2727
jest.resetModules();
2828
container = document.createElement('div');
29+
React = require('react');
2930
ReactDOM = require('react-dom');
3031
Scheduler = require('scheduler');
3132

@@ -587,6 +588,39 @@ describe('ReactDOMFiberAsync', () => {
587588
);
588589
});
589590

591+
it('regression test: does not drop passive effects across roots (#17066)', () => {
592+
const {useState, useEffect} = React;
593+
594+
function App({label}) {
595+
const [step, setStep] = useState(0);
596+
useEffect(
597+
() => {
598+
if (step < 3) {
599+
setStep(step + 1);
600+
}
601+
},
602+
[step],
603+
);
604+
605+
// The component should keep re-rendering itself until `step` is 3.
606+
return step === 3 ? 'Finished' : 'Unresolved';
607+
}
608+
609+
const containerA = document.createElement('div');
610+
const containerB = document.createElement('div');
611+
const containerC = document.createElement('div');
612+
613+
ReactDOM.render(<App label="A" />, containerA);
614+
ReactDOM.render(<App label="B" />, containerB);
615+
ReactDOM.render(<App label="C" />, containerC);
616+
617+
Scheduler.unstable_flushAll();
618+
619+
expect(containerA.textContent).toEqual('Finished');
620+
expect(containerB.textContent).toEqual('Finished');
621+
expect(containerC.textContent).toEqual('Finished');
622+
});
623+
590624
describe('createBlockingRoot', () => {
591625
it.experimental('updates flush without yielding in the next event', () => {
592626
const root = ReactDOM.createBlockingRoot(container);

packages/react-reconciler/src/ReactFiberWorkLoop.js

Lines changed: 9 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1713,7 +1713,15 @@ function commitRoot(root) {
17131713
}
17141714

17151715
function commitRootImpl(root, renderPriorityLevel) {
1716-
flushPassiveEffects();
1716+
do {
1717+
// `flushPassiveEffects` will call `flushSyncUpdateQueue` at the end, which
1718+
// means `flushPassiveEffects` will sometimes result in additional
1719+
// passive effects. So we need to keep flushing in a loop until there are
1720+
// no more pending effects.
1721+
// TODO: Might be better if `flushPassiveEffects` did not automatically
1722+
// flush synchronous work at the end, to avoid factoring hazards like this.
1723+
flushPassiveEffects();
1724+
} while (rootWithPendingPassiveEffects !== null);
17171725
flushRenderPhaseStrictModeWarningsInDEV();
17181726

17191727
invariant(

0 commit comments

Comments
 (0)