This tutorial is a companion to the Time art restoration post, which covers the project context and the original Flash-era reference. Here, we focus on how to build the interaction.
I will assume you already read the Dodge tutorial, so we will not re-teach basic React hooks, event cleanup, or why interactive state often belongs in useRef. Instead, this tutorial focuses on the new concepts: SVG geometry, recursive splitting, animation handoff, reverse merge, generated sound, and lifecycle cleanup.
The target experience is simple to describe: one square splits into smaller fragments, the fragments drift outward, then the process reverses until the square becomes whole again.
1. Model The Square Before Animating It
Start with data, not animation. The artwork may look visual and organic, but the system is easier to understand if every visible rectangle is just a plain object.
A fragment needs two groups of fields:
type Piece = {
id: string;
x: number;
y: number;
w: number;
h: number;
startX: number;
startY: number;
targetX: number;
targetY: number;
};x, y, w, and h describe the rectangle itself. startX, startY, targetX, and targetY describe motion. We keep those separate because the rectangle’s actual SVG geometry can stay stable while the browser animates it with a transform.
SVG is a better fit than Canvas for this tutorial step. In Dodge, Canvas was useful because we redrew the whole game scene every frame. Here, the scene is made from many persistent rectangles. SVG lets React render those rectangles as actual elements, and each element can animate independently.
The viewBox is the drawing coordinate system. It is similar to the Canvas width and height from Dodge, except SVG scales the coordinate system to whatever size the browser gives it.
<svg viewBox="0 0 1200 750">
{pieces.map((piece) => (
<rect
key={piece.id}
x={piece.x}
y={piece.y}
width={piece.w}
height={piece.h}
/>
))}
</svg>Checkpoint: You should be able to explain why the square is data first, why SVG is a good fit for persistent fragments, and why the motion fields are separate from the rectangle geometry.
One root piece rendered from a single object.
2. Split One Parent Into Two Children
Recursion is easier if the smallest operation is clear. Before splitting a whole tree, split one rectangle.
Each split chooses a direction. A vertical split creates a left child and a right child. A horizontal split creates a top child and a bottom child.
const ratio = 0.2 + Math.random() * 0.6;The ratio is clamped to the range 20% to 80%. That matters for readability. If the ratio were allowed to be 1%, a child could become a nearly invisible sliver. The artwork feels random, but the randomness is constrained.
Each child starts from the parent’s current visual position:
startX: parent.targetX,
startY: parent.targetY,That is the key handoff rule. If a child starts from the wrong coordinate, it will appear to pop into existence before moving. The parent should disappear at the same moment its children appear exactly where the parent was.
For a vertical split, the first child moves left and the second child moves right:
targetX: parent.targetX - force
targetX: parent.targetX + childWidth + forceThe preview shows one split only. Keep pressing the button and watch how the child sizes and directions change, but the visual rule stays the same: parent out, children in.
Checkpoint: You should be able to explain what ratio controls, why the children inherit the parent target position, and why replacing the parent atomically avoids visual jumps.
The parent is replaced by two child records.
3. Save The Recursive History
Now scale the one-split rule into a tree.
If the depth is 1, there are 2 pieces. If the depth is 2, there are 4 pieces. If the depth is 5, there are 32 pieces. In general, the final count is 2 ** depth.
The important structure is history:
history[0] = root
history[1] = two children
history[2] = four grandchildren
history[3] = eight fragmentspieces is only what the user sees right now. history remembers how we got there. That difference matters later because merging is not a separate geometry problem. Merging is just walking the saved history backward.
Use the preview slider to scrub through history[0], history[1], history[2], and so on. This should match the Sandpack exercise below: the level number changes, and the visible piece count doubles at each step.
The recursive build loop is short because splitPiece already owns the local geometry:
const history = [[root]];
for (let step = 0; step < depth; step += 1) {
const previousLevel = history[step];
const nextLevel = previousLevel.flatMap((piece) => splitPiece(piece, step));
history.push(nextLevel);
}Notice that the force gets smaller as step increases:
const force = baseForce * Math.pow(0.85, step);Deep fragments are smaller, so they should not drift as far as the original square. This is one of the details that makes the result feel physical instead of random.
Checkpoint: You should be able to explain the difference between the visible pieces array and the saved history array, and why the history is required for a clean merge.
Scrub through each saved level of the split tree.
4. Animate The Handoff
At this point, the geometry works, but the result still feels like a static diagram. The next step is motion.
The tempting approach is to update every piece’s x and y in React on every frame. Avoid that. At high depth, the piece count can reach hundreds or thousands. React should decide which pieces exist; the browser should handle frame-by-frame movement.
Each fragment becomes an SVG group with a rectangle inside it. The rectangle keeps its base geometry, and the group receives a transform:
const from = `translate(${piece.startX - piece.x}px, ${piece.startY - piece.y}px)`;
const to = `translate(${piece.targetX - piece.x}px, ${piece.targetY - piece.y}px)`;The subtraction is important. The rectangle is drawn at piece.x, but visually it should begin at piece.startX. The transform bridges that difference.
We use the Web Animations API:
element.animate(
[{ transform: from }, { transform: to }],
{
duration: 2200,
easing: 'cubic-bezier(0.05, 0.9, 0.1, 1)',
fill: 'forwards',
}
);fill: 'forwards' keeps the element at the final transform after the animation finishes. The easing curve gives the piece a fast initial push and a slow glide, closer to ice sliding than normal UI movement.
This chapter is the main bridge from “algorithm” to “art.” The same data model now feels continuous because the children start where the parent was and glide toward their targets.
Checkpoint: You should be able to explain why the rectangle geometry does not change every frame, why transform animation is cheaper, and how startX, x, and targetX work together.
Pieces inherit parent coordinates before sliding outward.
5. Reverse The Tree, Then Clean Up
The final interaction has two phases: split forward, then merge backward.
Because Chapter 3 saved history, the reverse phase can walk through it from deepest level to root. The important detail is that merge does not replace a whole level immediately:
for (let step = depth - 1; step >= 0; step -= 1) {
moveChildrenBackToTheirLocalOrigins(history[step]);
await wait(2200);
replaceChildrenWithRestoredParents(history[step]);
}During the merge phase, each child first animates back toward its own local starting position, meaning targetX becomes x and targetY becomes y. Only after that 2.2 second glide finishes do we remove those children and restore the parent rectangles. That delayed handoff is the part that prevents overlap, snapping, and the incorrect “whole level swap” behavior.
The full piece also adds sound. Each split plays a small generated bell:
const baseFreq = 180 + Math.random() * 330;
playTone(baseFreq, 0.1, 2.5);
playTone(baseFreq * 1.5, 0.05, 2.0);
playTone(baseFreq * 2.01, 0.03, 1.5);The non-integer harmonic 2.01 keeps the bell slightly unstable instead of perfectly clean. During merge, the envelope reverses so the sound swells inward instead of attacking outward.
Cleanup matters here because the interaction is asynchronous. It uses timers, animations, and audio nodes. If the user navigates away or switches tabs, those should stop.
return () => {
clearPendingWaits();
stopActiveNotes();
closeAudioContext();
};The final system is not just “recursion plus rectangles.” It is a sequence of handoffs: parent to children, visible state to history, JavaScript state to browser animation, split sound to merge sound, and active interaction to cleanup.
Checkpoint: You should be able to explain why the merge is the saved history in reverse, why audio follows the same split/merge structure, and why long-running creative code needs explicit cleanup.
The saved tree history plays backward into one square.