Async Unmounting

[brainkim]

WIP on Async Unmounting API.

Elements should be able to linger in the DOM for longer than they’re in the virtual element tree. This is primarily useful for exit animations. We don’t want every component to unmount asynchronously. After some dogfooding I think the following conditions feel the most ergonomic:

1. The element should be a component element.
2. The element should be a keyed element. This condition seem to catch a lot of false positives where we don’t actually want the rendered values to linger, and prevents unit tests from having to be changed. *
3. The component is either an async generator component or the cleanup method is called with a callback which returns a promise. This is the main mechanism behind async unmounting. Bonus points if we can somehow exclude async generator components which return immediately from this logic. **
4. The component is directly unmounted. Nested unmounts should not trigger lingering.

* Coming back to this list. I’m not 100% sure this should be a requirement.
** Coming back to this list again. I’m beginning to think we should exclusively use cleanup callbacks and ignore return() stuff. The reason being it’s pretty easy to deadlock an async generator and I don’t want lingering in that case.

Related issues in other repositories.

• Animating when adding/removing a single component facebook/react#226
• Asynchronous ComponentWillUnmount in React 16 facebook/react#11106
• Deferred unmounting RFC reactjs/rfcs#128
• Component Unmount: Allow non-duration based outro animations sveltejs/svelte#3847

July 27th 2020
I have async unmounting mostly working. Check out the transitions directory in the examples, which does the d3 enter-update-exit letters thingy. I need to write tests, which will be a pain.

The only thing blocking merge is I wanted to do async unmounting while also making performance upgrades. Specifically, the introduction of a “remove” method on the internal renderer API, and coordination of the “arrange” and “remove” methods. I’ve made one pass, but my current thinking is we have to change the return types of the “update”/“commit” methods, which is a refactoring I just don’t feel like doing right now. This would involve bringing back to life the “dirty start”/“dirty end” optimizations. Probably will pick this back up in a month.

Open questions:

• Should the return data include the start and end of the dirty range? If we do a flat boolean dirty flag, does that make arrange/remove optimizations worth it?
• If we do dirty start, dirty end, should the start and end be inclusive-inclusive, or inclusive-exclusive?
• Should the signature of arrange change?
• Should we add hints to the remove method as well, and are there any other optimizations we can make to the arrange/remove call stuff. For instance, should we call arrange once with an empty array in the case of no shared children? Increase the coordination of arrange and remove?

[brainkim]

Somehow moving src/index.ts to src/crank.ts wasn’t picked up by Git despite putting it in two separate commits. Might close and retry this PR rather than attempting to rebase 😓.

[brainkim]

Probably gonna have to retry this effort from scratch because of changes. 😓

[Scott-HangarA]

Hi did this get picked up elsewhere or how can I follow this? Thanks!

[brainkim]

@Scott-HangarA Weird coincidence! I’m literally diagramming how to implement this because I can’t go to sleep, and came back to this PR because I wanted to see my old notes. I’ll create a PR soon, but I should probably have done this as an issue to track it. It will probably be put into the next version (0.4), and I’ll reference any new work in this PR, so following this PR will still keep you up to date.

Here’s what I’m thinking about right now: How important is it that the position of exiting DOM nodes be preserved? Async unmounting would be so much simpler if we simply appended exiting DOM nodes to the end of whatever parent it was exiting from.

Pros of ignoring the “last position” of exiting nodes:

• Easier to implement
• You don’t have to worry about what happens when a parent element is rerendered while it has async unmounting children:
  • where should new nodes go relative to the exiting nodes?

Cons:

• Can’t rely on layout in exit animations (this is actually a huge con)
• Probably surprising behavior (another huge con)

[Scott-HangarA]

Thanks for the update! I could imagine a case where the exiting nodes might be needed in the same order. For example, using Material-ui it creates dropdowns/ drawers/ modals in nodes at the bottom of the page outside of the parent node. This raises the question (for me anyways) of what happens when someone has, let's say, a drawer open, and then navigates away? Below is an example from https://material-ui.com/components/drawers/

[brainkim]

@Scott-HangarA

This was me trying to figure out where exiting nodes should go at 6 AM this morning haha. Like, if you have nodes A, B, C, D, and rerender D, A, where should B and C be placed as they’re exiting. For some reason, I thought the most ideal behavior was B, C, D, A and was sketching out, frankly, some insane algorithms to produce this ill-specified behavior, but I realized after taking a walk that the most ideal behavior would probably be D, B, C, A, as in, preserve the original index of exiting nodes in the new children, which is a much simpler algorithm to implement. It’s still non-trivial to implement, but at least I’m a bit clearer on what the exiting placement behavior should be.

The real mind-f*ck which I don’t want to deal with is when you have multiple sets of exiting nodes which overlap in terms of when they’re exiting, where should they all be placed relative to each other.

Yes, the trick these exiting animations use is to recreate the original layout of the exiting nodes using fixed positioning and css transforms, but ideally we’d want to be able to preserve the DOM nodes where they were originally so we don’t have to do all that layout measurement.