What is the current behavior?
An (removed) Transition's state may stuck in entering after being removed from TransitionGroup. Unfortunately I've not managed to produce a easy-to-ready MVP. For reproducing, check the end of this issue.
Curiously, it seems that the root cause is that the Transition's componentDidUpdate hook's prevProps is changed without the hook being called, either by someone updating the props object directly, or by React somehow missing a render. The problem is that the in prop of this Transition is managed by TransitionGroup, so each update to the in prop should definitely cause (at least) one componentDidUpdate call.
If we add a log at the start of componentDidUpdate (for convenience, I directly edited the compiled version):
We can see that the Transition is at entering, with prevProps === this.props, but this.props.in === false.
What is the expected behavior?
The state should update correctly.
Reproducing
This issue manifests in https://github.com/jesec/flood, where the loading overlay sometimes fails to hide. In particular, after a successful login or logout, the loading overlay always stays. Related code is at https://github.com/jesec/flood/blob/25fe901c32b99eb68feed5e0abe2071b6420aec2/client/src/javascript/components/AppWrapper.tsx#L77-L83.
I've failed to reproduce this bug in a simplified setting. So this issue may be related to the upper levels of the component tree, and how they manage the tree. So for context, other components that I think might be involved:
- React version: 18.3.1
- Mobx: Using react integration, 7.6.0
- React-router-dom: Router used, but no
Route in upper levels. 6.30.1
Help needed
An easy fix is to drop the prevProps === this.props check at https://github.com/reactjs/react-transition-group/blob/master/src/Transition.js#L183, and instead skip the state update if not needed. I can confirm this fixes the issue. But given that this does not solve the root cause, this may be unsatisfactory.
I suspect in order to further track down the bug, more logs are needed. What more logging can I provide in order to help the maintainers fix this?
An (removed) Transition's state may stuck in
enteringafter being removed from TransitionGroup. Unfortunately I've not managed to produce a easy-to-ready MVP. For reproducing, check the end of this issue.Curiously, it seems that the root cause is that the Transition's
componentDidUpdatehook'sprevPropsis changed without the hook being called, either by someone updating the props object directly, or by React somehow missing a render. The problem is that theinprop of thisTransitionis managed byTransitionGroup, so each update to theinprop should definitely cause (at least) onecomponentDidUpdatecall.If we add a log at the start of
componentDidUpdate(for convenience, I directly edited the compiled version):We can see that the Transition is at
entering, withprevProps === this.props, butthis.props.in === false.The state should update correctly.
This issue manifests in https://github.com/jesec/flood, where the loading overlay sometimes fails to hide. In particular, after a successful login or logout, the loading overlay always stays. Related code is at https://github.com/jesec/flood/blob/25fe901c32b99eb68feed5e0abe2071b6420aec2/client/src/javascript/components/AppWrapper.tsx#L77-L83.
I've failed to reproduce this bug in a simplified setting. So this issue may be related to the upper levels of the component tree, and how they manage the tree. So for context, other components that I think might be involved:
Routein upper levels. 6.30.1An easy fix is to drop the
prevProps === this.propscheck at https://github.com/reactjs/react-transition-group/blob/master/src/Transition.js#L183, and instead skip the state update if not needed. I can confirm this fixes the issue. But given that this does not solve the root cause, this may be unsatisfactory.I suspect in order to further track down the bug, more logs are needed. What more logging can I provide in order to help the maintainers fix this?