Uncaught Error: Maximum update depth exceeded. #27

Activity

1. LenkasetSong commented on Sep 4, 2025

   

   LenkasetSong

   on Sep 4, 2025

   Last edited by LenkasetSong

   Author

   More actions

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

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

   可能是antd的bug
2. James-Jager commented on Nov 10, 2025

   

   James-Jager

   on Nov 10, 2025

   Contributor

   More actions

   Same exact issue
3. litvinenko-rc commented on Nov 18, 2025

   

   litvinenko-rc

   on Nov 18, 2025

   More actions

   It causes the same issue in rc-picker
4. James-Jager commented on Nov 19, 2025

   

   James-Jager

   on Nov 19, 2025

   Contributor

   More actions

   I have created a PR for this issue: #29
5. James-Jager commented on Nov 19, 2025

   

   James-Jager

   on Nov 19, 2025

   Last edited by James-Jager

   Contributor

   More actions

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

   ❤️React with ❤️1Reacted by lenkaset
6. litvinenko-rc commented on Mar 27, 2026

   

   litvinenko-rc

   on Mar 27, 2026

   Last edited by litvinenko-rc

   More actions

   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]);
7. nrps9909 commented on Aug 28, 2026

   

   nrps9909

   on Aug 28, 2026

   More actions

   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.