View Transitions Cross Framework

View Transitions Cross Framework

Overview

Build robust view transitions across major web stacks. Start from a minimal working transition, then layer custom CSS and framework-specific routing behavior.

Workflow

1. Identify transition scope: same-document (SPA), cross-document (MPA), or shared element.
2. Read references/core-api-and-css.md for base API and pseudo-element behavior.
3. Read references/support-matrix.md and pick the integration mode:

• framework-managed
• framework-assisted
• manual

4. Read exactly one framework reference:

• references/astro.md
• references/angular.md
• references/nextjs.md
• references/react-router-remix.md
• references/nuxt.md
• references/sveltekit.md
• references/qwik.md
• references/tanstack-router.md
• references/vanilla-js.md

5. Apply a pattern from references/pattern-library.md only after the baseline flow works.
6. Add fallbacks and prefers-reduced-motion handling before finalizing.
7. Verify navigation direction, back/forward behavior, and unsupported-browser behavior.

Implementation Rules

• Guard every startViewTransition usage and provide a no-animation fallback.
• Keep the update callback fast; do expensive async work before starting the transition when possible.
• Keep each view-transition-name unique among simultaneously rendered elements.
• Use cross-document transitions only for same-origin pages that opt in via CSS.
• Avoid running two transition systems on the same update path (for example manual DOM transitions plus framework-managed transitions).
• Respect reduced-motion users by shortening or disabling heavy motion.

Debugging Checklist

• Confirm the route/state update happens inside the intended transition boundary.
• Confirm no duplicate view-transition-name values are active at once.
• Confirm pseudo-elements exist with DevTools during the transition:
• ::view-transition-group(...)
• ::view-transition-old(...)
• ::view-transition-new(...)
• Confirm transition callback does not throw or reject.
• Confirm browser support and fallback path in non-supporting browsers.

Resource Map

• references/core-api-and-css.md: API lifecycle, pseudo-elements, custom CSS strategy, accessibility and fallback.
• references/support-matrix.md: integration choice by framework and maturity.
• references/astro.md: <ClientRouter />, transition:* directives, lifecycle hooks, fallback settings.
• references/angular.md: router-level view transitions via withViewTransitions.
• references/nextjs.md: React <ViewTransition>, Next.js experimental.viewTransition, caveats and production posture.
• references/react-router-remix.md: route transition APIs for React Router and Remix.
• references/nuxt.md: Nuxt configuration and per-page control.
• references/sveltekit.md: onNavigate integration pattern with native API.
• references/qwik.md: Qwik City defaults and qviewTransition.
• references/tanstack-router.md: navigate options and router-level defaults.
• references/vanilla-js.md: direct SPA/MPA implementations without framework abstraction.
• references/pattern-library.md: reusable animation recipes and safe defaults.
• references/framework-comparison-recipes.md: same animation recipe implemented across five stacks for copy/paste starts.

Expected Output Style

When implementing for a user request:

1. Produce runnable code first.
2. State exactly which transition type is implemented (SPA, MPA, shared element).
3. Include fallback behavior and reduced-motion handling.
4. Mention one concrete verification step the user can run immediately.