Loading Spinner to Checkmark — SVG Path Morph JS

Most "loading then success" button patterns swap two separate SVG elements — a spinning circle fades out while a checkmark path fades in. This snippet does something different and more literal: a single <path> element continuously reshapes its own coordinate data, morphing directly from a spinner arc shape into a checkmark or an X, depending on whether the simulated async action succeeds or fails.

Three point-matched shapes, one path element

spinnerPts, checkPts, and crossPts are each a 10-point array in a shared 0–64 SVG viewBox. Keeping every shape at exactly 10 points means any of the three can interpolate cleanly into either of the other two — the spinner can become a check, or become a cross, using the exact same lerpPath(a, b, t) function. Notice that checkPts and crossPts repeat several coordinates three times in a row ([22, 42], [22, 42], [22, 42], for instance) — this is a deliberate padding technique: a checkmark's natural shape only needs a few real vertices, but padding it with duplicate points at the corners keeps the array at the same length as the 10-point spinner, without changing how the checkmark actually looks, since duplicate consecutive points don't add extra geometry.

The spin phase is separate from the morph phase

While the async action is "in flight", the icon does not use path interpolation at all — it uses an ordinary CSS animation: spin 0.9s linear infinite rotating the whole <svg>, which is far cheaper than continuously recomputing path data for a shape that isn't actually changing. Only once the result is known does runFlow() stop the CSS spin and hand off to the JavaScript-driven lerpPath morph — using the right tool for each phase of the animation instead of forcing one technique to do both jobs.

Driving the morph itself

runFlow(pathEl, btn, endPts, endClass, endLabel) is a small state machine: it disables the button, starts the CSS spin, waits (via setTimeout, standing in for a real network request), then runs a requestAnimationFrame loop that interpolates the path's d attribute from spinnerPts to whichever endPts array was passed in — checkPts for the success button, crossPts for the failure button — over 380ms with a cubic ease-out curve. The same function drives both outcomes; only the target point array, the CSS class applied on completion, and the label text differ.

Why this reads as more "real" feedback than a crossfade

When two separate icons crossfade, there is a brief moment where both are partially visible, overlapping — a soft but slightly muddled transition. A single path genuinely changing shape has no such overlap: every frame is one continuous, unambiguous glyph, which tends to read as more deliberate and "designed" than an opacity blend, especially at small icon sizes where two overlapping icons can look visually noisy.

Extending to more outcomes

Because every shape lives in the same point-matched format, adding a fourth or fifth end state — a warning triangle, a paused/dash icon — is just a matter of designing one more 10-point array and calling runFlow with it; no changes to the morphing logic itself are needed.