How to support proper cleanup for effects that should only run once

[Andarist]

In #18 there are multiple patterns described for ensuring that an effect is only executed once - however, there is no symmetry for the cleanup phase. Given the provided APIs, I don't even think it's possible now because the real unmount and cleaning up because of Fast Refresh, strict effects, or using Offscreen is not distinguishable.

Why this might be important and what kind of use cases can't be easily implemented now?

1. File uploader that would like to cancel the ongoing upload in its cleanup - in here, one probably could refactor the file uploader in question, maybe prevent navigating away when the upload is in progress etc but it would require code refactoring and possible some communication with other parts of the app.
2. Timer-based action: reversible action with a 3-second timer that fires the real action after the time has passed. Assuming, for example, a list element with the timer that goes "offscreen".
3. Controlling a popup window (and thus properly closing it). For this one I have a codesandbox - in here, whenever the WindowPortal truly unmounts the popup should be closed as well (imagine for example a print preview opened in the popup). This is a situation when we certainly don't want to accidentally close the popup.

I don't think those are abstract problems, even if I have provided a codesandbox only for one of them (so far). I admit that those kinds of situations (where the cleanup just can't be arbitrary called) are less common but I truly believe that there are more situations like this and those are just 3 that came to my mind - all of which I've seen in production codebases.

[gaearon]

File uploader that would like to cancel the ongoing upload in its cleanup - in here, one probably could refactor the file uploader in question, maybe prevent navigating away when the upload is in progress etc but it would require code refactoring and possible some communication with other parts of the app.

Can you clarify why you wouldn’t want a “hide” to be treated the same way as “unmount” here? From the user perspective they would look the same. Why should one cancel but not the other?

Timer-based action: reversible action with a 3-second timer that fires the real action after the time has passed. Assuming, for example, a list element with the timer that goes "offscreen".

Similar question. If it shouldn’t be cancelled when a row goes off view, why should it be cancelled when a user navigates to another page, for example? This sounds like a case where you wouldn’t want to clean up the timer in either case unless the user explicitly cancels it. So it sounds like a use case for an event handler rather than for effect cleanup.

(In fact, I'd argue that this kind of UI needs to send a signal to the backend immediately — so that if the user closes the tab before the period elapses, after a bit of time the action still happens. The backend timeout could be larger to account for network delays.)

Controlling a popup window (and thus properly closing it). For this one I have a codesandbox - in here, whenever the WindowPortal truly unmounts the popup should be closed as well (imagine for example a print preview opened in the popup). This is a situation when we certainly don't want to accidentally close the popup.

Why would it be "accidental"? Consider something like navigating top-level tabs in an app. If you go from Feed to Profile, from the user perspective, that's a navigation, and the old screen "disappears". Why shouldn't that close the popup?

In case of virtualized rows, if you put the popup effect into a row, it would already close today (because the row would get unmounted). So why would the same behavior be a problem? It seems like either way you'd want to hoist that effect out of the row component and into something closer to the top, which has the right "lifetime". For example, the closest page.

---

The common thread between my replies is that cleaning up effects is already the current behavior when something is removed from the screen. So from the user's perspective, things that got "cancelled" or "destroyed" still get "cancelled" and "destroyed" during the same interactions (like a route change). The only difference is that we can keep some state alive.

If you don't want to "cancel"/"destroy" effects, then instead of using the new Offscreen feature, you would always render the content and hide it yourself (e.g. with display: none). This is also just like React works today.

[gaearon]

For an example of what a “hide” means, consider something like switching top-level tabs on Twitter or FB. From the user perspective it does look exactly like “unmount”. It’s just that we want to preserve the state (and/or things like scroll position, in some cases).

[gaearon]

Just pinging to see if this helped or if it's still vague.

[gaearon]

I wonder if reframing this feature differently would help. (We’re still figuring out ways to talk about this well — please bear with us! These conversations are very helpful.)

Imagine we introduce it like this. Imagine there are no concepts like “show and hide”. Let’s say we still just have “mount and unmount”. But! The new feature is that we offer a way to opt into preserving state between unmount and next mount. That’s the feature.

Would that framing change your perspective on any of these cases?