3 ms·

Note that you don’t really have to “animate something before it’s removed from the DOM”. A “disappearing” animation is an embellishment and a purely visual eff

Note that you don’t really have to “animate something before it’s removed from the DOM”. A “disappearing” animation is an embellishment and a purely visual effect; therefore, it only depends on what the original object looked like, not the entire original object itself. It is a lot simpler to reason about the state of your system if you delete items immediately and create proxies to handle special effects for deletion. For example, to have an element “animate away”: create a new purely-visual element at an absolute location that looks like the original object, delete the original object immediately, and then let the proxy go away whenever it is done animating. This completely frees you from having to worry about the true lifetime of the original object.

untog 7y ago
> For example, to have an element “animate away”: create a new purely-visual element at an absolute location that looks like the original object, delete the original object immediately, and then let the proxy go away whenever it is done animating. This completely frees you from having to worry about the true lifetime of the original object. The OPs point is that doing this is far more DOM-intensive, and leads to worse performance. It isn't a good solution.
dmitriid 7y ago
> For example, to have an element “animate away”: create a new purely-visual element at an absolute location that looks like the original object, delete the original object immediately, and then let the proxy go away whenever it is done animating. This completely frees you from having to worry about the true lifetime of the original object. Yeah, and to properly do that you need that very same JS bloat to: - somehow observe a DOM element being destroyed (there are no lifecycle methods on DOM objects) - somehow figure out if it's the object being destroyed, or it's parent, or grandparent, or... - somehow quickly create a visual proxy instead of the object being destroyed, quickly substitute it in the DOM (avoiding repaints, reflows and jank). With all the correct things for it: size, position, scroll position, all internal representation (let's say we're animating a login form floding in on itself) - somehow animate that proxy object - and then remove that proxy object. It's a lot simpler By the way. If I remember correctly, just getting the position of an object causes a full-page reflow [1] [1] https://gist.github.com/paulirish/5d52fb081b3570c81e3a https://gist.github.com/paulirish/5d52fb081b3570c81e3a

untog 7y ago

dmitriid 7y ago

> For example, to have an element “animate away”: create a new purely-visual element at an absolute location that looks like the original object, delete the original object immediately, and then let the proxy go away whenever it is done animating. This completely frees you from having to worry about the true lifetime of the original object. Yeah, and to properly do that you need that very same JS bloat to: - somehow observe a DOM element being destroyed (there are no lifecycle methods on DOM objects) - somehow figure out if it's the object being destroyed, or it's parent, or grandparent, or... - somehow quickly create a visual proxy instead of the object being destroyed, quickly substitute it in the DOM (avoiding repaints, reflows and jank). With all the correct things for it: size, position, scroll position, all internal representation (let's say we're animating a login form floding in on itself) - somehow animate that proxy object - and then remove that proxy object. It's a lot simpler By the way. If I remember correctly, just getting the position of an object causes a full-page reflow [1] [1] https://gist.github.com/paulirish/5d52fb081b3570c81e3a https://gist.github.com/paulirish/5d52fb081b3570c81e3a