Closed Haemoglobin closed 6 months ago
mark
that's because when useEffect is triggered when your setSomeState return false, it can't make component rendered, but in react's alternate Fiber Tree, it keeps references to variables a function dispatchAction<S, A>( fiber: Fiber, queue: UpdateQueue<S, A>, action: A, ) { if (DEV) { if (typeof arguments[3] === 'function') { console.error( "State updates from the useState() and useReducer() Hooks don't support the " + 'second callback argument. To execute a side effect after ' + 'rendering, declare it in the component body with useEffect().', ); } }
const eventTime = requestEventTime(); const lane = requestUpdateLane(fiber);
const update: Update<S, A> = { lane, action, eagerReducer: null, eagerState: null, next: (null: any), };
This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment!
Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue with up-to-date information. Thank you!
Hi,
It seems that there is a memory leak issue when using the set state hook lambda syntax, and setting the state to the previous state. The set state lambda in this scenario seems to be retained and never garbage collected.
Please ignore the contrived example, it's intentionally whittled down to the exact issue. It's quite a common requirement in our application to subscribe to an rxjs observable in a useEffect hook, then update some state when events are received (but the data received might not always result in a state change). The lambda syntax is required in the set state call because current state would otherwise always be the default state due to the closure around it in the useEffect hook. Even if there was another way to do it to avoid the issue, it's still a surprising behaviour and makes it harder to fall into the 'pit of success'.
Reproduction below:
The best memory profiler to see this is the 'Allocation instrumentation on timeline' mode in chrome devtools.
I have confirmed this also happens using production / minified bundles so it's not a dev build issue.
Right now as a workaround I need to use 'hacks' like useRef and forceUpdate implementations which is a real shame so keen to see this fixed.
Possibly related to #21692 Many thanks!