Uncaught Error: Maximum update depth exceeded.

[LenkasetSong]

react-dom-client.development.js:3860 Uncaught Error: Maximum update depth exceeded. This can happen when a component repeatedly calls setState inside componentWillUpdate or componentDidUpdate. React limits the number of nested updates to prevent infinite loops.
at getRootForUpdatedFiber (react-dom-client.development.js:3860:1)
at enqueueConcurrentHookUpdate (react-dom-client.development.js:3820:1)
at dispatchSetStateInternal (react-dom-client.development.js:6966:1)
at dispatchSetState (react-dom-client.development.js:6927:1)
at Portal.js:63:1
at Object.react_stack_bottom_frame (react-dom-client.development.js:23953:1)
at runWithFiberInDEV (react-dom-client.development.js:1519:1)
at commitHookEffectListMount (react-dom-client.development.js:11905:1)
at commitHookPassiveMountEffects (react-dom-client.development.js:12026:1)
at commitPassiveMountOnFiber (react-dom-client.development.js:13841:1)

https://github.com/react-component/portal/blob/master/src/Portal.tsx

React.useEffect(() => {
const customizeContainer = getPortalContainer(getContainer);

// Tell component that we check this in effect which is safe to be `null`
setInnerContainer(customizeContainer ?? null);

});
是不是此处导致的，还是我外部使用不对导致的？

[LenkasetSong]

antd : Slider的tooltip会导致这种情况 Tooltip

如果类似这样的用法：
{state <= 10000 && <Slider
min={1}
max={10000}
value={state}
tooltip={undefined}
onChange={(v) => setState(v)}
/>}

可能是antd的bug

[James-Jager]

Same exact issue

[litvinenko-rc]

It causes the same issue in rc-picker

[James-Jager]

I have created a PR for this issue: #29

[James-Jager]

If you need a fix right away I just used patch-package made the changes needed(see PR) and generate the post install patch.

[litvinenko-rc]

The issue still persists in 2.2.0.
Patching the problematic useEffect like this works though:

  React.useEffect(() => {
    const customizeContainer = getPortalContainer(getContainer);

    // Tell component that we check this in effect which is safe to be `null`
    setInnerContainer(() =>
    // React do the state update even the value is the same,
    // Use function call to force React to compare update
    customizeContainer ?? null);
-  });
+  }, [getContainer]);

[nrps9909]

This appears resolved in the current release.

PR #29 was merged as af740b2 with the functional state updater that forces React to compare the resolved container before scheduling another render. The fix is included in the @rc-component/portal@2.2.1 tag, and npm currently reports 2.2.1 as latest. The report above that still reproduced on 2.2.0 therefore predates the released fix.

The effect intentionally still runs after each render: a stable getContainer callback can close over a ref whose current element changes, so depending only on the callback identity would miss a legitimate container switch. The functional updater prevents the unchanged-container loop while preserving that behavior.

This issue should be eligible for maintainer closure. If it still reproduces on 2.2.1, a minimal example should include the exact getContainer callback and whether it returns a stable element or creates a new element on every call.

AI assistance disclosure: Codex was used to trace the merged PR, release tag, npm version, and current container effect; I verified the commit ancestry and tagged source before posting.