[RFC Proposal] Stop updating Transition's slot while a transition is taking place

[ferferga]

Hello. I'm opening this with the aim to gather some feedback on whether there's interest in having this in Vue's core. In my opinion, my proposal fits into the "small enough" area to not go into the RFC process yet (besides, I don't have a PR yet), and that's why I'm opening it under the "General" topic (but feel free to let me know or to move this discussion there) .

Motivation/Summary

When a component is transitioning, state mutations can trigger DOM changes. These can sometimes break the appearance of animations, like in this snippet:

Vuetify Playground

Fire the snackbar and wait a few seconds for it to close. Check how the color of the snackbar changes to white while the transition is taking place. More backrgound here: vuetifyjs/vuetify#17180

Here's another example where this problem might be annoying. In this example, we will deal with a large list (10000 items) and we want to toggle the visibility using v-show, but also kill all the DOM nodes when they're hidden to free up resources:

1. In the first case, we simply have a transition that fires after a v-show change. In DevTools, you can see how all the nodes are still present in the tree: Vue Playground

2. If we want to kill all the DOM nodes, we need an v-if too! However, that breaks transitions as the DOM is patched: Vue Playground

3. This is not a problem of the Vue's scheduler patching the DOM before the Transition component takes the change, since this is also reproducible if we add another property that tracks the animation's state: Vue Playground

4. 3 is also reproducible if we set an interval that takes less than the transition itself: Vue Playground

5. The current solution everybody is doing to solve this problem is very similar to what has been done in 3) and 4): have 2 variables, one that tracks the model state and another that tracks the rendering itself. With the after-leave hook, we have an effective workaround: Vue Playground

Proposed solution

There are two things that could be done into the leave and after-leave hooks of Transition to solve this:

Stop dependency/effect tracking of the child component recursively.

This one probably introduces a lot of edge cases and will be really difficult to implement, besides being more prone to breaking watchers, computed properties, etc... And probably will make the implementation much more difficult, since the Transition component itself relies in the the state of the component to know when it needs to fire the transition*

Stop Vue's patch process.

Inside Vue, only Transition should be manipulating the DOM nodes in the "paused" state of the patcher to add the CSS styles and event handler needed for the correct functionality of the component:

· Entering component:

• sync flush timing:
  • Patch the slot's content with the new state (the same that triggered Transition)
  • Apply (if necessary) the pre-transition styles
  • [...]
  • All the enqueued DOM updates are finished and a new cycle starts
• Stop patcher and apply event handlers and the rest of the styles that finally start the CSS transition
• Transition starts
• after-leave:
  • Resume patcher.
  • Add to the patcher's scheduler any state change during the transition.
  • Patcher applies the changes
  • [...]
  • All the enqueued DOM updates are finished and a new cycle starts

· Leaving component:

• pre flush timing:
  • Stop patcher
  • Apply (if necessary) the pre-transition styles
• Apply event handlers and the rest of the styles that finally start the CSS transition
• Transition starts
• after-leave:
  • Resume patcher.
  • Add to the patcher's scheduler any state change during the transition.
  • Patcher applies the changes
  • [...]
  • All the enqueued DOM updates are finished and a new cycle starts

Adoption strategy

This new behaviour should be the default for Transition, since I think it's what most people expect. A patchable | modifiable boolean prop (with proper documentation) could be added to the component to keep the current behaviour.

Drawbacks

None that I'm aware of

Alternatives

Approach 5) in the Motivation/Summary section.

Additional context

• I'm not going too deep into my proposal since I just did a surface inspection of Teleport source code and, although I consider myself proficient enough in "userland" Vue, I'm just starting to become more and more interested in Vue's internals and there are probably a lot of things that I'm missing. Please, forgive any lack of precision. Any detailed explanation or further precision of the fine details to get this proposal to a good point is more than welcome!
  • That's why I used flush timing to roughly describe how my proposition should work, as I assume the patcher and watcher's flush timing are essentially the same.
  • Also, why I'm not aware of any drawbacks.
• I can look into implementing this myself as soon as this thread gets some feedback, but I don't have anything against somebody else taking the challenge either and doing it before me.

[ferferga]

Work that is going to help make this RFC possible is already live at vuejs/core#9206 (comment) and vuejs/core#9651

[ferferga]

Digging more into this, it looks like this is a common source of trouble that framework authors have been dealing, since besides the Vuetify threads linked in the main post, Radix Vue also had the same issue. They workaround this using their Presence component

@zernonia Do you think all the use cases of Radix will be covered by this proposal? Any edge case you think that might be missed by pausing effects while transitions are running? Given you develop a component library and have some experience with Presence, any API suggestion to have this feature upstream? Thank you very much in advance,

[jods4]

IMHO This has a big potential for edge cases and unforeseen consequences.

A few random comments, but I'm sure more will be uncovered if people experiment with this:

• While I agree that the majority of the time it's ok/expected to freeze leaving components, I am really not sure this applies to entering components as well (as your proposal suggests to also freeze entering components). I've seen several demos of the relatively new CSS view transitions where emphasis was put on "content is still live during the transition!!".
• You mention CSS transitions, but what about JS transitions (e.g. orchestrated ones)? Callbacks onLeave and onBeforeLeave are meant to be used for doing JS-driven animations and although they are rather vanilla-JS oriented (they pass an HTMLElement), nothing is preventing the user to capture Vue state or find it back from the element and attempt to update the DOM through state changes. A flag to control this behaviour is definitely needed and if we want to avoid potentially breaking changes it should remain "live" by default.
• How does this interact with interruptible animations? E.g. consider the dropdown list of a combobox, could be driven by a v-if or maybe v-show. If the user clicks quickly you want to interrupt the ongoing animation and "invert" the animation from current state (ideally preserving velocity, MotionOne feels so good for those things). If you're not patching the state during the leave animation, is this still going to work?
• Thinking long-term: leave transitions are inherently hard and hacky; CSS view transitions are going to be a much better solution for this. Right now they only support singleton (document-level) transitions but there's ongoing work to extend them to element-level transitions. After this lands, this kind of complicated hacks will be unnecessary, so is it worth investing in those or can we continue as-is for a few more years?

[ferferga]

@jods4 Apologize for taking so long to reply, been busy these weeks and I've been delaying this more and more.

While I agree that the majority of the time it's ok/expected to freeze leaving components, I am really not sure this applies to entering components as well (as your proposal suggests to also freeze entering components). I've seen several demos of the relatively new CSS view transitions where emphasis was put on "content is still live during the transition!!".

This doesn't change at all with the current behaviour (unless I'm misunderstanding something). When a component is enabled by v-if, the entire VNode tree of that component is appended to the DOM and then transition starts. If it didn't happen in that order, what DOM node would the Transition component append the CSS classes/JS events to?
With my proposal it would work like this:

• Vnode is mounted with the equivalent behaviour of the v-once directive
• Transition plays
• v-once is turned off

You mention CSS transitions, but what about JS transitions (e.g. orchestrated ones)? Callbacks onLeave and onBeforeLeave are meant to be used for doing JS-driven animations and although they are rather vanilla-JS oriented (they pass an HTMLElement), nothing is preventing the user to capture Vue state or find it back from the element and attempt to update the DOM through state changes. A flag to control this behaviour is definitely needed and if we want to avoid potentially breaking changes it should remain "live" by default.

I don't understand what's the issue with this, can you give an example? If an user wants to manipulate the DOM outside Vue, of course nothing we can do to stop them from doing so, but that's irrelevant!
The current behaviour that happens when you manually modify the DOM outside Vue will happen in this case: once the patcher needs to patch the element, Vue's VDom will overwrite those changes as it will unaware that they happened in the first place.

How does this interact with interruptible animations? E.g. consider the dropdown list of a combobox, could be driven by a v-if or maybe v-show. If the user clicks quickly you want to interrupt the ongoing animation and "invert" the animation from current state (ideally preserving velocity, MotionOne feels so good for those things). If you're not patching the state during the leave animation, is this still going to work?

Is as simple as: Transition happening -> patcher paused. Transition not happening -> patcher running

So in your example, a quick v-if sucession of false - true -false would:

• Mount component as v-once.
• Transition appends enter animation classes and events, pauses patcher
• Component is toggled false
• Enter transition finished, patcher resumes
• Transition appends close animation classes and events, pauses patcher
• Transition ends, component is unmounted

This is the same behaviour as now

Either case, this being opt-in means that users can simply skip adding the freeze prop if they don't like the behaviour.

Thinking long-term: leave transitions are inherently hard and hacky; CSS view transitions are going to be a much better solution for this. Right now they only support singleton (document-level) transitions but there's ongoing work to extend them to element-level transitions. After this lands, this kind of complicated hacks will be unnecessary, so is it worth investing in those or can we continue as-is for a few more years?

This is a really good point, though I didn't have enough time to play with the API yet to see how much this would help in all situations. I understand your point about the main point of CSS View Transition API is to have content live while it's transitioning, but this is not what is always desired. My Vuetify playground is the best example of this, I don't want it to go white at all, just fade away! Yes, I could change the color on an @afterLeave, but that's way too verbose.

Beyond the usability, I think another interesting point that we should bring into the table is the performance improvements it could bring: pausing activity and manipulation of the DOM in the main thread while a transition is working and it's undesired will always be a welcome thing that View Transition API will never solve because it's completely out of it's scope.