Feature Request: New lifecycle behavior to allow components to delay their own unmounting

[bdwain]

Doing some sort of animation right before a component unmounts is currently very difficult. Being able to delay unmounting by adding a callback to componentWillUnmount (like react transition group's componentWillLeave), or adding a new lifecycle method with this functionality (componentIsReadyToUnmount?) would be very helpful for this.

The use case where this has come up for me is a list item with a button in it, where clicking the button dispatches a redux action that causes some async work to be done (instead of doing it right in the component). On success, the item is removed from the list. Before it is removed, I'd like to give feedback that the action was successful by showing a checkmark in the button for a second.

Ideally, this logic would live in a button component, making it really easy to reuse anywhere you have a button. But in order for that to work, the button component itself needs to be able to delay its own unmounting. Ideally with something like this:

//button.js
componentIsReadyToUnmount(callback){
  if(this.props.isSuccessful){
     setTimeout(() => callback(), 1000);
  }
  else{
     callback();
  }
}

Currently, this has to be done by preventing all parents of the button from being unmounted also. My current implementation handles this all in redux by delaying the state updates caused by the async work. That logic is purely for display purposes though, and doesn't really belong there. It also makes it hard to replicate that behavior across different types of lists.

I've also looked at react transition group for this also, but that only works if the transition group element itself is not unmounted. This would make it hard to keep around an object like a button that is deeply nested inside an element that will be removed.

I recognize that misuse of this feature would lead to confusing/hard to debug behavior and very poor performance, but I think the risk is worth it considering the way this kind of behavior currently needs to be implemented. I think that risk could also be mitigated with useful development mode warnings. One example could be a warning logged if a component holds up unmounting for more than X seconds (X could be globally configurable somehow, with a sensible default).

[syranide]

#6067 (comment) is perhaps the short answer but the entire thread is about the same issue.

[bdwain]

@syranide if this solution won't work, do you know if there is currently any effort being made to address the problem? This is a pretty common problem, and the response in the thread you linked made it sound like no effort would be made to fix it.

[syranide]

@bdwain It's not a problem with React, you need to adjust and extend your components as necessary. It's easily provable that it is solvable in different ways, you just need to find the one that works best for your use-case. What you're asking for from React doesn't really work in practice, and even if it did would break a lot of very important assumptions in React.

React just takes data and renders it, if it doesn't exist then it can't be rendered. If you want something to stay rendered after being "removed" then you need to find a way retain the data and render it. Even when it is technically considered "removed" in your app (e.g. soft remove).

[syranide]

PS. If you need more in-depth help then I recommend then community forum or stackoverflow.

[aweary]

Since this is a dupe of #6067 I'm going to close it recommend you post any feedback on the topic there @bdwain, so as to not split the conversation.