DEV Community: Zsolt Szabó

Part 3: Exit animations

Zsolt Szabó — Thu, 13 Mar 2025 10:58:17 +0000

In Part 1 and Part 2, we built an animated list that animates layout changes and supported properties. We used AnimDiv, AnimNode, and a hook to connect them. The list supports enter animations, but exit animations are missing. In this post, we will add them.

Elements, Children and reconciliation

The issue with exit animations is that, at this point, we should play them on elements that we won’t even render (since they’ve been removed from the list props). So what can we do? If we look at the motion package documentation, we see that we should use an AnimatePresence wrapper in these cases. So, what can this component do?

First, we need to understand what our function components return and how components are updated.

function Container() { 
  return (
    <div>
      <Item name='item1'/>
      <Item name='item2'/>
    </div>
  );
}

What happens when my Container component is updated? Will it automatically update the Item components and run all the hooks inside them? The answer is: No. It just returns a React.Node tree (or, with some simplification, a React.Element tree). These are plain lightweight JavaScript objects that contain information about the element, like its type, props, etc.

After that, React compares this result with the previous one and decides what to update / mount / unmount.

If the type is the same and its position in the tree is the same, or it has a key prop that was previously present (maybe at a different position), React will just update the component.

So, what's different when we're using children props? Nothing. React doesn't care whether we received an element as a prop and used it in our result or just created it locally.

Children props are usually just used as-is in the result; otherwise, it would be pretty difficult to reason about our code. But in some cases, it's okay to deconstruct the list or modify the items, and this is one of those cases.

AnimPresence implementation

The idea is that the AnimPresence component will track and store its children. When a child is removed, it will temporarily keep it in the output until the exit animation finishes.

To simplify things, only React.Element nodes with keys will be kept temporarily. Other node types will be filtered out, and elements without a key will be removed immediately.

There’s still the question of how we’ll notify items to start their exit animation and how we’ll be notified when their animations finish. We won’t solve this within the AnimPresence component. Instead, we’ll delegate this to a component that will wrap each individual child element, called PresenceChild, and handle it later.

type PresenceTrackedChild = {
  element: ReactElement;
  isPresent: boolean;
};

export function AnimPresence({ children: _children }: PropsWithChildren) {
  const children = useMemo(() => filterElements(_children), [_children]);

  const [trackedChildren, setTrackedChildren] = useState(
    convertToTracked(children),
  );

  const childrenChanged = useChangeDetection(children);
  if (childrenChanged) {
    const newTrackedChildren = mergeChildrenLists(trackedChildren, children);
    setTrackedChildren(newTrackedChildren);
  }

  return trackedChildren.map(({ element, isPresent }) => {
    const optionalKey = element.key;
    if (optionalKey === null) {
      return element;
    }

    const key = optionalKey;

    return (
      <PresenceChild
        key={key}
        isPresent={isPresent}
        onSafeToRemove={() => {
          setTrackedChildren((children) =>
            children.filter(
              (child) => child.element.key !== key || child.isPresent,
            ),
          );
        }}
      >
        {element}
      </PresenceChild>
    );
  });
}

function mergeChildrenLists(
  oldTrackedChildren: PresenceTrackedChild[],
  newChildren: ReactElement[],
) {
  const childrenKeys = nonNullElementKeys(newChildren);
  const newTrackedChildren = convertToTracked(newChildren);
  oldTrackedChildren.forEach((oldTracked, index) => {
    const key = oldTracked.element.key;
    if (key !== null) {
      if (!childrenKeys.includes(key)) {
        newTrackedChildren.splice(index, 0, {
          ...oldTracked,
          isPresent: false,
        });
      }
    }
  });

  return newTrackedChildren;
}

First, we filter out child nodes that are not React.Elements (like text nodes).
Then, we map child elements to objects that contain the element itself and an isPresent flag.
useChangeDetection is a utility hook that returns true when its parameter changes from the previous update.
mergeChildrenLists inserts removed child elements back into the new children list at their last known index.
Finally, we wrap elements that have a key prop with PresenceChild components.

PresenceChild implementation

For this component, we can "cheat" again by checking the motion documentation for hints on how they implemented it. They use a usePresence hook that returns the presence state and a safeToRemove callback, which should be called when the exit animation finishes.

We'll follow the same approach by creating a React.Contextwith these two properties and implementing a usePresence hook to access them.

export function PresenceChild({
  children,
  onSafeToRemove,
  isPresent,
}: PresenceChildProps) {
  const contextValue = {
    onSafeToRemove,
    isPresent,
  };

  return (
    <PresenceChildContext.Provider value={contextValue}>
      {children}
    </PresenceChildContext.Provider>
  );
}

export function usePresence(): UsePresenceResult {
  const context = useContext(PresenceChildContext);
  return {
    isPresent: context?.isPresent,
    safeToRemove: context.onSafeToRemove.bind(context),
  };
}

This implementation has a few issues, tough.

What happens when components using the usePresence hook are not wrapped by an AnimPresence component?

In this case, the context is undefined. Usually, this would be an error (we forgot to wrap components with a Provider). But for us, this should be a valid use case (there might not be any exit animations for example).

What happens if a child doesn’t use the usePresence hook at all?
The safeToRemove callback will never be called, and removed items will be kept indefinitely. To fix this, we need to track whether the hook is used. We should only wait for the safeToRemove call when we know the child component uses it. Otherwise, we can remove the child element immediately.

So, we’ll add another callback to our context: preventImmediateRemoval. This callback won’t be exposed through the usePresence hook but will be called whenever the hook executes. In PresenceChild this will set a boolean ref to indicate whether we should wait for safeToRemove or not.

export function PresenceChild({
  children,
  onSafeToRemove,
  isPresent,
}: PresenceChildProps) {
  // will be set to true when a component in the subtree uses the `usePresence` hook
  const isRemovalDeferred = useRef(false);

  const contextValue = {
    onSafeToRemove,
    isPresent,
    preventImmediateRemoval: () => (isRemovalDeferred.current = true),
  };

  useEffect(() => {
    if (!isPresent && !isRemovalDeferred.current) {
      onSafeToRemove();
    }
  }, [isPresent, onSafeToRemove]);

  return (
    <PresenceChildContext.Provider value={contextValue}>
      {children}
    </PresenceChildContext.Provider>
  );
}

export function usePresence(): UsePresenceResult {
  const context = useContext(PresenceChildContext);
  if (!context) {
    // It's completly valid to use this hook without <AnimPresence> wrapper
    // in that case nothing will defer the unmouning of the element,
    // so isPresent can always be true, and safeToRemove is a no-op.
    return {
      isPresent: true,
      safeToRemove: () => {},
    };
  }

  // when a component uses this hook we can assume that it will handle the removal process
  // and eventualy it will call safeToRemove at some point
  context.preventImmediateRemoval();
  return {
    isPresent: context?.isPresent,
    safeToRemove: context.onSafeToRemove.bind(context),
  };
}

Support exit animations in AnimDiv

First, we need to add a new exit prop to our component.

type AnimDivOwnProps = {
  initial?: Animation;
  animate?: Animation;
+  exit?: Animation;
  options?: AnimationOptions;
};

We'll use the usePresence hook we just implemented. Since the target animation can now change based on the isPresent state, we'll use a target ref to store the currently active animation.

Additionally, we need to reimplement the layout effect that triggers animations and make it dependent on the isPresent state.

function useAnimNode({ initial, animate, exit, options }: UseAnimNodeParams) {
  ...

  const target = useRef<Animation>(undefined);
  const { isPresent, safeToRemove } = usePresence();

  ...

  useLayoutEffect(() => {
    if (isPresent && target.current !== animate) {
      target.current = animate;
      animNode.animateTo(target.current ?? {}, target.current?.options);
    } else if (!isPresent && target.current !== exit) {
      target.current = exit;
      animNode.animateTo(target.current ?? {}, target.current?.options);
      animNode.setFinishedAnimatingCallback(() => {
        safeToRemove();
      });
    }

    return () => {
      animNode.setFinishedAnimatingCallback(undefined);
    };
  }, [isPresent, animate, exit]);

  ...
}

The finish animating callback will be called by AnimNode when the animations Set becomes empty.

Now after updating our List component and setting the exit property, we can check the motion implementation (left) and our own implementation (right) side by side.

The two look almost identical with some minor animation curve differences.

You can view the full code or check the diff from Part 2.

Part 2: Property animations

Zsolt Szabó — Thu, 13 Mar 2025 10:56:02 +0000

In Part 1, we built an animated list using AnimDiv, AnimNode, and a hook to connect them. We also added a simple fade-in animation for the list items. But everything was hardcoded. In this part, we will make it more customizable.

Our goal is to create an API similar to the one in the motion package. We want to set initial values for the properties, define animation targets, and control duration and the easing function. For now, we won't handle exit animations—that will come in Part 3.

<motion.div
  layout
  key={id}
  initial={{ opacity: 0, transition: { duration: 0.3 } }}
  exit={{ opacity: 0, transition: { duration: 0.3 } }}
  animate={{ opacity: 1, transition: { duration: 0.2 } }}
  transition={{ duration: 0.2 }}
>
  {renderItem(id)}
</motion.div>

Extending the AnimDiv props

First, we define the types we will use:

export type Properties = {
  x: number;
  y: number;
  opacity: number;
};

export type AnimationEasing =
  | "linear"
  | "ease"
  | "ease-in"
  | "ease-out"
  | "ease-in-out";

export type AnimationOptions = {
  duration?: number;
  easing?: AnimationEasing;
};

Properties includes the animation properties we support. For this tutorial these are limited to x, y, and opacity.
AnimationOptions defines the duration and easing function.

To use these as props in AnimDiv, we need to make them optional and pass them to the useAnimNode hook:

export type Animation = Partial<Properties> & {
  options?: AnimationOptions;
};

type AnimDivOwnProps = {
  initial?: Animation;
  animate?: Animation;
  options?: AnimationOptions;
};

export type AnimDivProps = ComponentProps<"div"> & AnimDivOwnProps;

In the useAnimNode hook, we synchronize props with the AnimNode instance. Since layout animations start in afterUpdate, we run this logic between beforeUpdate and afterUpdate using layout effects. This is fine as long as it's inexpensive and doesn’t modify any React state.

function useAnimNode({ initial, animate, options }: UseAnimNodeParams) {
  const animNodeRef = useRef<AnimNode>(new AnimNode());
  const animNode = animNodeRef.current;

  animNode.beforeUpdate();

  useLayoutEffect(() => {
    animNode.mount(initial);
    return () => {
      animNode.unmount();
    };
  }, []);

  useLayoutEffect(() => {
    animNode.setDefaultOptions(options ?? {});
  }, [options]);

  useLayoutEffect(() => {
    animNode.animateTo(animate ?? {}, animate?.options);
  }, [animate]);

  useLayoutEffect(() => {
    animNode.afterUpdate();
  }, []);

  return {
    animNode,
    domRef: (el: HTMLDivElement) => {
      animNode.setDomElement(el);
    },
  };
}

We are modifying the existing mount function to accept an initial values parameter and we are adding the setDefaultOptions and animateTo functions. Next, we’ll implement these in AnimNode.

Public vs Internal types

In AnimNode, we could reuse the Animation type we defined earlier. However, it's better to use a separate type that fits our animation approach (Element.animate).

Keep in mind that we could use a different solution (or switch to it in the future), like manual property animations, where x and y can be separate. But with our current method, these two animate a single property: translate.

Users don’t need to know about these internal details, but for us, it’s easier to convert everything to a format that uses translate instead of x and y separately.

const kAnimationProperies = ["translate", "opacity"] as const;
type AnimationProperty = (typeof kAnimationProperies )[number];

type AnimationTarget = {
  [p in AnimationProperty]?: string;
} & {
  options?: AnimationOptions;
};

We can use a single array with the supported style properties and derive the other types from it. This way, we have one source of truth for the properties we support.

How to start animations

Just like layout changes don't trigger animations immediately, animateTo won't either. We will store the previous animation target, just like we did with the layout information. New animation requests will be registered, and changes will be handled in the afterUpdate method.

export class AnimNode {
  ...
+  private animationTarget: AnimationTarget = {};

-  private prevLayout?: LayoutProperties;
+  private prev: {
+    layout?: LayoutProperties;
+    target: AnimationTarget;
+  } = { target: {} };

  afterUpdate() {
    if (!this.domElement || !this.isMounted) {
      return;
    }

+    if (this.prev.target !== this.animationTarget) {
+      this.handleTargetChange();
+    }

    const layout = calcLayoutProperties(this.domElement);
    if (this.prev.layout && hasLayoutChanged(this.prev.layout, layout)) {
      this.handleLayoutChange(this.prev.layout, layout);
    }
  }
  ...
}

To figure out how we want to animate to a new target, we need to consider the most complex scenario: receiving a new target while a previous animation is still active.

We can't use the composite: "add" trick we used for layout animations because these values aren't additive. For example, if an opacity animation goes from 0 to 0.5 and is interrupted by another one going to 0.7, we can't just add the values together. Doing so could exceed the target value, even going over 1, which doesn't make sense. So, we need to use "replace" mode instead.

The problem with "replace" mode is that it overrides the previous animation's values. So, we need a way to start the new animation exactly from where the previous one left off and decide what to do with the active animation.

Fortunately, we can use implicit from keyframes, which means we only provide the target value, and the browser will figure out the starting value for us. This way, we don’t need to cancel the active animation, as canceling would reset to its starting state.

For the fill option, we’ll use 'forwards' to keep the final values after the animation ends. This allows us to commit the styles and remove the animation when it's done without any glitches.

 private animateProperty(
    property: AnimationProperty,
    to: string,
    { duration, easing }: AnimationOptions = {},
  ) {
    if (!this.domElement) {
      return;
    }

    const animation = this.domElement.animate(
      { [property]: to },
      {
        duration:
          duration ??
          this.defaultAnimationOptions.duration ??
          kGlobalAnimationOptions.duration,
        easing:
          easing ??
          this.defaultAnimationOptions.easing ??
          kGlobalAnimationOptions.easing,
        composite: "replace",
        fill: "forwards",
      },
    );

    this.registerAnimation(animation);
  }

The animateProperty method starts an animation for a single property. We could animate all properties at once, but handling them separately means that if only one property changes, we don’t have to restart the entire animation - just start a new one for that property.

In my opinion this is preferable because the easing function will "reset" (it's a new standalone animation after all), which will break the natural continuous flow of the animation. The difference is that with separate animations, only the affected properties will be impacted instead of all of them. But ultimately this is a product decision rather than a technical necessity.

  private handleTargetChange() {
    const target = this.animationTarget;
    const prevTarget = this.prev.target;

    kAnimationProperties.forEach((property) => {
      const targetValue = target[property];
      const prevTargetValue = prevTarget[property];

      if (targetValue !== undefined) {
        if (prevTargetValue === undefined || targetValue !== prevTargetValue) {
          this.animateProperty(property, targetValue, target.options);
        }
      } else {
        // skip
      }
    });
  }

Enter animations

Now that we have a working property animation solution, we need to set initial values to enable enter animations. We have already decided that the mount method will handle this:

  mount(initialValues: Partial<Properties> = {}) {
    this.isMounted = true;

    if (!this.domElement) {
      throw new Error("AnimNode: mounting without a dom element");
    }

    const initialAnimationValues = toAnimationTarget(initialValues);
    kAnimationProperties.forEach((property) => {
      if (initialAnimationValues[property] !== undefined) {
        this.domElement!.style[property] = initialAnimationValues[property];
      }
    });

    this.prev.target = initialAnimationValues;
  }

Now that all the building blocks are in place, we can finally use them in our List component. You can try experimenting with the initial and animate props - using x values, so items slide in from the left for example.

The last step is to support exit animations, which will be covered in Part 3.

You can view the full code or check the diff from Part 1.

Part 1: Animate layout changes

Zsolt Szabó — Thu, 13 Mar 2025 10:55:44 +0000

What are we building?

We are creating an animated list component. It will take an array of IDs and a renderItem function as props. The component arranges items in a row on large screens and in a column on smaller screens. When the list updates, it animates items to their new positions, fades in new items, and fades out removed ones.

This component is easy to implement with the Motion package. Here’s how we could do it:

import { ReactNode } from "react";
import { AnimatePresence, motion } from "motion/react";
import "@/List/list.css";

type ListItemId = number | string;

type ListProps<IdType extends ListItemId> = {
  ids: IdType[];
  renderItem: (id: IdType) => ReactNode;
};

export function List<IdType extends ListItemId>({
  ids,
  renderItem,
}: ListProps<IdType>) {
  return (
    <div className="list-root">
      <AnimatePresence>
        {ids.map((id) => (
          <motion.div
            layout
            key={id}
            initial={{ opacity: 0, transition: { duration: 0.3 } }}
            exit={{ opacity: 0, transition: { duration: 0.3 } }}
            animate={{ opacity: 1, transition: { duration: 0.2 } }}
            transition={{ duration: 0.2 }}
          >
            {renderItem(id)}
          </motion.div>
        ))}
      </AnimatePresence>
    </div>
  );
}

Before implementing our own version, we should prepare the following:

copy the list component into a new folder and replace the <motion.div> elements with regular <div> elements for now.
create a card component. In this tutorial we will displays Pokémons based on their IDs, using the pokedex npm package.
set up an example page where we can switch between the Motion version and our implementation or show both side by side.
create hardcoded ID arrays for updating the lists.

You can view the full code here: https://github.com/qwerjoe/blog-diy-animated-list/tree/start

Design decisions

Before we start coding, we need to make some important choices

What do we mean by layout change?

In this project, by layout we only refer to the 2D (x, y) positions of elements. We will ignore their size.

There are two common ways to get an element’s position:

offsetLeft / offsetTop – these values are relative to the element’s parent (offsetParent). They ignore extra CSS transformations.
getBoundingClientRect() – returns values relative to the viewport and includes transformations like scaling or translation.

For our specific use case, offsetLeft / offsetTop is clearly the better choice.

Being relative to the viewport doesn’t offer any advantage here.
Being relative to the parent actually makes sense — if the parent moves, we don’t want to treat it as a layout change for the child element.
offsetLeft / offsetTop ignores extra transformations, which is a big plus. Since we’ll animate these elements, using getBoundingClientRect() would require negating our own transformation effects just to detect layout changes correctly.

Which layout changes do we want to animate?

Let's think about when offsetLeft / offsetTop might change:

React updates that modify the DOM.
resizing the window or a parent component (e.g., flex-wrap moves an item to a new row)
style changes (caused by explicit attribute changes or media queries or changing the element hierarchy).
external scripts modifying the DOM.

Should we animate the change in every scenario? NO! (short answer)

Longer answer: It’s a business decision.

Technically, we could run a requestAnimationFrame loop to detect every offset change (while triggering layout recalculations on every frame, and causing performance issues). There might be use cases where this trade-off is justified, in ours it's definitely not.

In our case, we only want to animate layout changes when a React state update causes our component to re-render. In all other cases, elements will instantly move to their new position without any animation.

How to Animate?

There are several ways to animate elements:

CSS transition animations
CSS keyframe animations
Element.animate() (JavaScript API)
manual property animations using React state
manual property animations outside of React

Why not CSS animations?

CSS keyframe animations could be useful for a somewhat customizable animation set, but with the level of control we need, predefining every animation in a stylesheet before playing it isn’t practical.

CSS transitions could work, but they can be tedious to manage as there’s only one transition property. If you need different durations or easing functions for different animations (enter, exit, etc.), you must carefully keep them in sync.

Also, if an animation needs to start from a value other than the element’s current state, you have to unset the transition property, set the starting value, then after a small delay reapply the transition before updating to the target value.

And if you ever want to add more complex animations, simple transitions won’t be enough.

Why not manually animate properties?

Manually updating property values gives you full control and allows any kind of animation behavior. But it's by far the most complex solution.

Motion internally uses this method to support both HTML and 3D object animations and to implement their physics-based spring interpolations. For our simplistic use case though, this would be an overkill.

Anyways if you ever need to implement custom animations, never rely on React state. Keep in mind that React state changes will trigger re-renders that might affect the entire application tree, while smooth animations require updates every 33.3ms (30 FPS). A React re-render could block or delay these updates, causing janky animations.

Our Pick: JavaScript API

The Element.animate() function comes with all the benefits of CSS keyframe animations but we can configure and manage everything from code. The composite and fill options, along with the ability to commit styles, will help when blending multiple animations modifying the same property.

However, blending animations can still be tricky with this approach. If it becomes a problem later, our only alternative would be to implement custom manual animations.

Implementation

The core logic will be handled in the AnimNode class, which will be responsible for starting and managing animations. The <AnimDiv> component will be our version of the <motion.div> component. These two will be connected by the useAnimNode hook.

Let's begin by writing some code for the AnimNode class.


export class AnimNode {
  private isMounted: boolean = false;
  private domElement?: HTMLElement | null;
  private animations: Set<Animation> = new Set();

  setDomElement(element: HTMLElement | null) {
    this.domElement = element;
  }

  private registerAnimation(animation: Animation) {
    this.animations.add(animation);

    const removeAnimation = this.removeAnimation.bind(this, animation);
    animation.addEventListener("finish", removeAnimation);
    animation.addEventListener("cancel", removeAnimation);
    animation.addEventListener("remove", removeAnimation);
  }

  private removeAnimation(animation: Animation) {
    animation.cancel();
    this.animations.delete(animation);
  }

  mount() {
    this.isMounted = true;

    if (!this.domElement) {
      throw new Error("AnimNode: mounting without a dom element");
    }
  }

  unmount() {
    this.isMounted = false;
    for (const animation of this.animations.values()) {
      animation.cancel();
    }
    this.animations.clear();
  }
}

It doesn’t do anything yet. You can set the DOM element it will control, we added some utility methods to track active animations and implemented basic mount / unmount lifecycle methods.

Now, the interesting part: how will we detect layout changes? We'll create two functions: one to run before the layout might change, and another to run after. In the first function, we'll save the layout values. In the second one, we'll compare the saved and the new values and trigger a layout animation if they are different.


type LayoutProperties = {
  top: number;
  left: number;
};

function calcLayoutProperties(element: HTMLElement): LayoutProperties {
  return {
    left: element.offsetLeft,
    top: element.offsetTop,
  };
}

function hasLayoutChanged(prev: LayoutProperties, current: LayoutProperties) {
  return prev.left !== current.left || prev.top !== current.top;
}

export class AnimNode {
  private prevLayout?: LayoutProperties;

  ...

  beforeUpdate() {
    if (this.domElement && this.isMounted) {
      this.prevLayout = calcLayoutProperties(this.domElement);
    }
  }

  afterUpdate() {
    if (!this.domElement || !this.isMounted) {
      return;
    }

    if (!this.prevLayout) {
      // first update
      return;
    }

    const layout = calcLayoutProperties(this.domElement);
    if (hasLayoutChanged(this.prevLayout, layout)) {
      this.handleLayoutChange(this.prevLayout, layout);
    }
  }

  private handleLayoutChange(
    prevLayout: LayoutProperties,
    layout: LayoutProperties,
  ) {
    if (!this.domElement) {
      return;
    }

    const delta = {
      top: prevLayout.top - layout.top,
      left: prevLayout.left - layout.left,
    };

    const translateFrom = `${delta.left}px ${delta.top}px`;
    const translateTo = "0px 0px";

    const animation = this.domElement.animate(
      [{ translate: translateFrom}, { translate: translateTo }],
      {
        duration: 200,
        easing: 'ease-out',
        composite: "add",
        fill: "both",
      },
    );

    this.registerAnimation(animation);
  }

  ...

}

In the handleLayoutChange method, we'll calculate the vector that points from the new position to the old position. The animation will move from these values to (0, 0).

For the fill option, we use 'both', which will immediately set the starting value on the element, making it look like it's still in the "old" position.

The 'add' composite option is for handling concurrent layout animations. Since our layout animation target is always (0, 0), we can combine these animations by adding their values together. Using 'replace' would cause a noticeable jump when a layout animation starts while others are still active.

Now, all that's left is to implement AnimDiv and useAnimNode.

We'll call the beforeUpdate method directly in the function body, which runs when the function component updates / re-renders. The afterUpdate method will be called inside a useLayoutEffect, which runs synchronously right after the DOM is updated.

import { ComponentProps, useLayoutEffect, useRef } from "react";
import { AnimNode } from "./AnimNode";

export type AnimDivProps = ComponentProps<"div">;

export function AnimDiv({ ...divProps }: AnimDivProps) {
  const { domRef } = useAnimNode();
  return <div {...divProps} ref={domRef} />;
}

function useAnimNode() {
  const animNodeRef = useRef<AnimNode>(new AnimNode());
  const animNode = animNodeRef.current;

  animNode.beforeUpdate();

  useLayoutEffect(() => {
    animNode.mount();
    return () => {
      animNode.unmount();
    };
  }, []);

  useLayoutEffect(() => {
    animNode.afterUpdate();
  }, undefined);

  return {
    animNode,
    domRef: (el: HTMLDivElement) => {
      animNode.setDomElement(el);
    },
  };
}

This is necessary because if we used useEffect, React could give
the control back to the browser after updating the DOM. At that point, the browser might repaint the page before running the effect, causing a visual glitch where the element jumps to its new position then jumps back and starts moving.

useLayoutEffect prevents this issue, but it's important to keep it lightweight and avoid updating React state within it, as that could trigger unintended side effects.

Now our animated layout updates work seamlessly with React state changes. We can even add a simple hack to create hardcoded enter animations:

  afterUpdate() {
    if (!this.domElement || !this.isMounted) {
      return;
    }

    if (!this.prevLayout) {
      // first update -- fade in object
      const animation = this.domElement.animate(
        [{ opacity: 0 }, { opacity: 1 }],
        {
          duration: kGlobalAnimationOptions.duration,
          easing: kGlobalAnimationOptions.easing,
          composite: "replace",
          fill: "both",
        },
      );

      this.registerAnimation(animation);
    }

    const layout = calcLayoutProperties(this.domElement);
    if (this.prevLayout && hasLayoutChanged(this.prevLayout, layout)) {
      this.handleLayoutChange(this.prevLayout, layout);
    }
  }

You can view the full code here: https://github.com/qwerjoe/blog-diy-animated-list/tree/hardcoded-animations

What’s Next?

If this is all you need, then we’re done! In fact, we could even simplify the code by merging AnimNode into the useAnimNode hook. But if you want more - like customizable enter/exit animations - keep reading because the next parts of this tutorial will cover these topics.

Thanks for reading!