React

Verified against Claude Code · 2026-07-27

Implement a smooth transition between two UI states in React

Implements an enter/exit or shared-element transition using the lightest mechanism that actually produces the described motion — CSS, startTransition, or the View Transition API — instead of defaulting to a heavy animation library.

Claude CodeCursorChatGPTClaude

The prompt

Ready to copy — highlighted parts are example details you can swap.

<role>
You are implementing a specific UI transition in React. You pick the lightest mechanism that actually produces the described motion, not a default reach for a full animation library.
</role>

<transition>
When a card in a grid is clicked, it should visually expand into a full detail view that appears to grow from the card's position, not just appear instantly in a new location.
</transition>

<current_code>
A CardGrid component that renders CardPreview items, and a separate CardDetail route that currently just replaces the whole page instantly on click.
</current_code>

<animation_approach>
Preferred approach, if specified: Motion (formerly Framer Motion)
</animation_approach>

<selection_rules>
- If the transition is a simple property change (opacity, transform, color) tied to a class or data-attribute toggle, implement it with a CSS transition and let React only toggle the class/state — don't reach for a JS animation library for something CSS already animates natively and more cheaply.
- If the transition needs to happen while a state update or navigation would otherwise cause a jarring instant swap, wrap the state update in startTransition (or useTransition's function) so React can keep showing the old UI, marked as pending, until the new content is ready — this addresses timing, not the visual motion itself.
- If the transition is a genuine shared-element or cross-DOM-tree animation (an item morphing from a list into a detail view), and the target platform supports it, use the View Transition API — React's experimental ViewTransition integration if the project's React version has it, or the native browser API directly otherwise — since this is the one case CSS transitions and startTransition genuinely can't do on their own.
- Only bring in an external animation library (for example Motion) when the transition involves physics-based motion — spring, drag, gesture-driven — that CSS and the View Transition API don't model.
- Respect prefers-reduced-motion for any transition longer than a subtle micro-interaction — either skip it or replace it with an instant or cross-fade equivalent.
</selection_rules>

<output_format>
1. Which mechanism you chose and the one-sentence reason it's the lightest fit for this specific transition.
2. The implementation.
3. The prefers-reduced-motion fallback.
</output_format>
Customize the highlighted detailsoptional — the prompt above already works

Why this works

This is a decision-tree prompt before it's a code-generation prompt, and the actual failure mode it prevents is the default reach for a full animation library on a transition a CSS transition already handles for free — that's a real, avoidable bundle-size and complexity cost for zero additional visual benefit. Separating startTransition from the View Transition API matters because they solve genuinely different problems that get conflated constantly: startTransition changes when React commits new content and keeps the old UI interactive while marked pending, but it does not animate anything by itself, while the View Transition API is the one mechanism that can actually morph an element's position and size across a DOM change — treating them as interchangeable is a common and specific mistake this prompt heads off by name. The prefers-reduced-motion rule is included because it's a real, testable accessibility requirement, not a nice-to-have, and it's the detail a plain "make it animate" request reliably skips.

What you get back

Chosen mechanism: the View Transition API — this is a genuine shared-element case (the card needs to visually morph into the detail view), which CSS transitions and startTransition alone can't produce. function CardGrid({ cards }) { const navigate = useNavigate(); const openCard = (id) => { if (document.startViewTransition) { document.startViewTransition(() => navigate('/card/' + id)); } else { navigate('/card/' + id); } }; // each CardPreview gets style={{ viewTransitionName: 'card-' + card.id }} // and CardDetail's root element gets the matching viewTransitionName } Reduced-motion fallback: check window.matchMedia('(prefers-reduced-motion: reduce)').matches before calling startViewTransition — if true, navigate directly with no transition, since the API's default cross-fade is still enough visual change to be worth skipping for users who've opted out of motion.

Verified against

Claude Code Sonnet 4.6 · 2026-07-27

Claude Sonnet 4.6 · 2026-08-01

Changelog

  • 2026-07-27 Initial publish, verified against Claude Code and Claude on Sonnet 4.6.

Need this built into your business?

If a prompt isn't enough — custom software, built and maintained for you — that's Scult's day job.

EXPLORE CUSTOM SOFTWARE
All React prompts

Check your AI visibility

One URL in, a 0–100 score and the exact fixes out.

RUN THE CHECK

Browse all the tools

15 tools across six categories
13 of them never send your data anywhere

Free · No signup · No trial clock

SEE THE DIRECTORY