DEV Community: Bishop Z

Motion (motion/react) in production: layout animations and accessible motion patterns

Bishop Z — Mon, 15 Jun 2026 17:10:48 +0000

If you've used framer-motion in the last few years, you might not realize the library has moved on without you. Since late 2024, the package is just Motion, the import path is motion/react, and the API surface is cleaner than it's ever been. Most tutorials haven't caught up. They still show framer-motion imports, bouncing boxes, and no accessibility story.

This article is different. We'll build one component — an expandable card list — and use it to cover three things that matter in production: the motion/react import path and what the rebrand means for your codebase, layout animations in a real component tree, and accessible motion via useReducedMotion with a pattern that actually works.

Live demo → Open the StackBlitz project — fork it, break it, rebuild it. Every code block below comes from that demo.

Prerequisites. Comfortable with React hooks and TypeScript. Motion v12+ on React 18.

The rebrand: framer-motion → motion/react

In late 2024, Matt Perry separated Motion from Framer the company. The npm package became motion, and the React-specific import path moved to motion/react. The API itself didn't break — if you're on v11, the v12 upgrade is a find-and-replace.

npm uninstall framer-motion
npm install motion

Then swap every import:

// before
import { motion, AnimatePresence } from 'framer-motion';

// after
import { motion, AnimatePresence } from 'motion/react';

That's it for most codebases. If you're in a monorepo where some packages still reference framer-motion, both can coexist during migration — they're separate npm packages with no shared global state. But don't let that coexistence linger. Pick a sprint, do the swap, and move on.

Every import in this article uses the modern motion/react path.

The example we're building

We're building an expandable card list — three to five cards, each with a header that's always visible and a detail panel that mounts and unmounts on click. It's the kind of component you'd find in a Polaris or Spectrum design system page, not a demo with colored boxes.

Fork it, break it, rebuild it. Every code block in this article is pulled directly from that demo.

Layout animations in a real component tree

Most tutorials explain layout with a single element changing size. That's fine for understanding the concept, but it falls apart the moment you have a parent-child relationship where both the list and the individual items need to animate. Here's how to think about it in a real component tree.

Auto-layout with `layout`

The layout prop tells Motion to watch an element's position and size. When either changes — because a sibling mounted, a parent resized, or the element's own content changed — Motion automatically animates the transition instead of letting the browser snap to the new layout.

In our card list, the ul and each li use layout="position". That slides siblings when a card grows or shrinks, but does not scale the card itself — full layout applies transform-based size animation and will squash fixed headers and titles. Height changes stay inside the card: the detail panel uses a CSS grid accordion (0fr → 1fr), not layout on the list item.

import { motion, AnimatePresence } from 'motion/react';
import { useState } from 'react';
import { useMotionPreset } from '../hooks/useMotionPreset';
import { Card } from './Card';
import type { CardData } from '../data/cards';

export const ExpandableCardList = ({ cards }: { cards: CardData[] }) => {
  const [expandedId, setExpandedId] = useState<string | null>(null);
  const transition = useMotionPreset();

  return (
    <motion.ul layout="position" transition={transition} className="card-list">
      {cards.map((card) => (
        <motion.li key={card.id} layout="position" transition={transition}>
          <Card
            card={card}
            expanded={expandedId === card.id}
            onToggle={() =>
              setExpandedId(expandedId === card.id ? null : card.id)
            }
            transition={transition}
          />
        </motion.li>
      ))}
    </motion.ul>
  );
};

Sharing identity with `layoutId` and `AnimatePresence`

layoutId is the judgment call most tutorials skip. When two elements share a layoutId, Motion treats them as the same visual object — even if they're in completely different parts of the tree. This is how shared-element transitions work (think: a thumbnail that expands into a detail view).

In our card component, we don't need layoutId for the shared-element pattern. We need AnimatePresence for something simpler: the detail panel mounts and unmounts, and we want an exit animation. Without AnimatePresence, React removes the element from the DOM before Motion can animate it out. For the height transition, avoid animating to height: 'auto' — springs round to pixel heights, clip the last line during the tween, then snap when the style hands off to auto. Use a CSS grid wrapper (grid-template-rows: 0fr → 1fr) with overflow: hidden and padding on an inner child instead.

import { motion, AnimatePresence } from 'motion/react';
import type { CardData } from '../data/cards';
import type { Transition } from 'motion/react';

interface CardProps {
  card: CardData;
  expanded: boolean;
  onToggle: () => void;
  transition: Transition;
}

const detailTransition = (transition: Transition) => {
  if ('duration' in transition && transition.duration === 0) {
    return transition;
  }

  return {
    opacity: transition,
    gridTemplateRows: { type: 'tween' as const, duration: 0.35, ease: [0.4, 0, 0.2, 1] as const },
    height: { type: 'tween' as const, duration: 0.35, ease: [0.4, 0, 0.2, 1] as const },
  };
};

export const Card = ({ card, expanded, onToggle, transition }: CardProps) => (
  <div className="card">
    <button
      onClick={onToggle}
      aria-expanded={expanded}
      className="card-header"
    >
      <h3>{card.title}</h3>
      <p>{card.summary}</p>
    </button>
    <AnimatePresence initial={false}>
      {expanded && (
        <motion.div
          key="detail"
          initial={{ gridTemplateRows: '0fr', opacity: 0 }}
          animate={{ gridTemplateRows: '1fr', opacity: 1 }}
          exit={{ gridTemplateRows: '0fr', opacity: 0, height: 0 }}
          transition={detailTransition(transition)}
          className="card-detail-wrapper"
          style={{ display: 'grid' }}
        >
          <div className="card-detail">
            <p>{card.body}</p>
          </div>
        </motion.div>
      )}
    </AnimatePresence>
  </div>
);

The distinction matters: layout is for elements that stay in the DOM but move. AnimatePresence is for elements that enter and leave the DOM. layoutId is for when you want Motion to treat two different DOM nodes as one continuous visual object. In a real component tree, you'll often use all three together. Our card list uses layout="position" on list items plus AnimatePresence on the detail panel. Split responsibilities: siblings reflow with position layout; height animates only inside the grid wrapper. Never size-animate a container that holds text you need to stay crisp.

Accessible motion: useReducedMotion in production

The prefers-reduced-motion media query is not optional. About 30% of iOS users have it enabled (not all for vestibular disorders — some just don't like animation). If your motion strategy is "turn everything off," you're doing it wrong.

The common antipattern is gating the entire component — wrapping your <motion.div> in a conditional that falls back to a plain <div>. This breaks layout animations entirely. The list snaps, the siblings teleport, and your carefully crafted expand/collapse behavior degrades to a content pop.

The right pattern: gate the transition, not the component. The <motion.div> stays in the tree. It still manages layout. It just does it instantly instead of over 300ms.

import { useReducedMotion } from 'motion/react';

export const useMotionPreset = () => {
  const shouldReduce = useReducedMotion();
  return shouldReduce
    ? { duration: 0 }
    : { type: 'spring' as const, stiffness: 350, damping: 30 };
};

This single hook feeds every transition prop in the card list. When the user has prefers-reduced-motion: reduce set, all animations resolve instantly. The layout still works — elements still end up in the right place — they just get there without the spring. Expand a card with reduced motion on, and the detail panel appears immediately. Collapse it, and it disappears immediately. No jank, no teleportation, no broken layout.

Production teams should extract this into a shared utility. If your app has more than one animated component, every transition should flow through the same useMotionPreset hook. That gives you a single control surface for motion behavior across the entire application.

Motion vs. the Web Animations API

If you don't need React, don't need layout animations, and your animations are simple keyframe sequences — use the browser-native Web Animations API. It's zero dependencies, runs on the compositor thread, and performs well. A CSS @keyframes fade-in doesn't need a JavaScript library.

Motion wins when you need a React-native API that understands the component lifecycle. Layout animations that track DOM position changes, AnimatePresence for exit animations on unmounting components, spring physics that feel right without hand-tuning cubic beziers, and a declarative API that composes with React state — that's what a library buys you. The expandable card list we just built would be significantly more code and significantly less reliable with raw WAAPI.

What to try next

If you've worked through the demo, here are three specific things to try that push the pattern further.

Motion-aware design tokens. Replace the hardcoded spring values in useMotionPreset with design tokens from your system. A motion.standard token that returns the right transition for your brand's feel, gated by reduced-motion, is a powerful primitive.
Scroll-linked animations with useScroll. Add a sticky card header that fades in as you scroll past the card list. useScroll returns a MotionValue you can pipe into opacity and transforms without triggering re-renders.
Extract the pattern into a reusable hook. The expand/collapse + layout animation + accessible transition combo is generic enough to wrap in a useExpandable hook. Your future self will thank you when the second expandable component shows up.

This article originally appeared on bishopz.com. I write about production React, design systems, and the things tutorials skip. If you're hiring for design engineering or frontend architecture roles — let's talk.

Love Street v1.2 on Android

Bishop Z — Thu, 08 Jan 2026 17:21:33 +0000

Love Street is a playful productivity game that helps you make progress without the pressure. Unlike traditional task managers that feel like homework, Love Street combines beautiful design, gentle gamification, and thoughtful features to make getting things done actually enjoyable. Track both one-time goals and daily habits, add notes to capture context, explore game-like interactions, and watch your progress accumulate through automatic journaling. With no nagging notifications, a luxury casual aesthetic, and features like Snooze and Space Out to reduce overwhelm, Love Street adapts to how you actually work — not how productivity gurus think you should. Perfect for goal-oriented thinkers, people with executive dysfunction, or anyone who's abandoned every other productivity system they've tried.

The Production Readiness Gap: What AI and Bootcamps Don't Teach About Backend Engineering

Bishop Z — Fri, 25 Jul 2025 17:20:02 +0000

Originally published on my blog, but I wanted to share some practical takeaways with the Dev.to community

I used to think "full-stack engineer" meant "bad at frontend." Turns out, frontend developers make the same mistake in reverse—we learn Express routes and assume we're backend engineers.

Whether you're using AI to generate your backend or transitioning from frontend development, there's a gap between "it works on my machine" and "it works reliably for thousands of users."

The Real Backend Skills Nobody Talks About

It's not about syntax. Most developers can pick up Node.js or Python relatively quickly. The hard part is understanding the operational practices that keep systems running.

Here are the areas I see developers struggle with most:

1. Architecture Beyond Routes

// What most tutorials show you
app.get('/users/:id', async (req, res) => {
  const user = await db.query('SELECT * FROM users WHERE id = ?', [req.params.id]);
  res.json(user);
});

// What production systems actually need
// Separated controllers, services, and data access layers

2. Data Migrations (Including Frontend State!)

Your database needs migrations. But so does your frontend state in localStorage. When you change data structures, existing users break your app.

3. Security That Goes Deeper Than Input Sanitization

The OWASP Top 10 isn't just a checklist—it's a mindset shift about thinking like an attacker.

4. Monitoring That Actually Helps

Setting up alerts that wake you up for the right reasons, not every minor hiccup.

Quick Production Readiness Checklist

I put together this checklist based on the most common issues I see:

🔒 Security

[ ] Parameterized queries (no string concatenation)
[ ] Input validation on all endpoints
[ ] Rate limiting implemented
[ ] Secrets in environment variables, not code
[ ] HTTPS everywhere

📊 Monitoring

[ ] Health check endpoint
[ ] Error logging (but not sensitive data)
[ ] Performance metrics collection
[ ] Alerting on critical failures
[ ] Database connection monitoring

🚀 Deployment

[ ] Database migrations automated
[ ] Rollback procedure documented
[ ] Environment-specific configs
[ ] Zero-downtime deployment strategy
[ ] Load balancer health checks

🗃️ Data

[ ] Backup strategy implemented
[ ] Migration scripts tested
[ ] Data validation in application layer
[ ] Proper indexing on query patterns

The Full Deep Dive

I wrote a comprehensive guide covering all of these topics in detail, with specific examples and code samples: Full Stack Soft Skills: A Frontend Developer's Guide to Backend Engineering Practices

The guide includes:

Architecture patterns with real code examples
Frontend state migration strategies
Security practices beyond the basics
Monitoring and alerting best practices
Deployment strategies that actually work at scale
Step-by-step operational procedures

Discussion Questions

I'm curious about the Dev.to community's experiences:

What production issue surprised you most when you first deployed a backend application?
For those using AI to generate code - what operational practices do you wish AI tools included automatically?
What's one backend concept you wish someone had explained to you earlier in your career?

Let's help each other bridge this gap. Drop your experiences, questions, or additional tips in the comments!