React View Transitions

For app-level implementation:

• Wrap the smallest stable visual unit that should animate.
• Use explicit, stable names for shared elements, for example name={"item-" + id}.
• Give each reordered list item its own ViewTransition; a boundary around the whole list animates the subtree as one layer.
• Treat className="none" or a resolved class of "none" as an opt-out.
• Keep urgent input updates outside view-transition-eligible work when keyboard or pointer responsiveness matters.

For debugging:

• Start by validating that React and React DOM are on a channel that exposes <ViewTransition />.
• Confirm the old and new elements have matching view-transition-name values when expecting a share transition.
• Check whether the element is outside the viewport; React may revert names for an exiting offscreen element.
• Distinguish layout-only movement from content updates. React uses the Update flag as a proxy and has known rough edges here.
• For list reordering, verify each child gets a unique transition name rather than relying on DOM-order matching.
• For Suspense or streaming behavior, remember that browser view transitions are atomic and cannot animate partially revealed intermediate states.

For React internals:

• Read the architecture reference before making claims about commit phase ordering, callbacks, gesture clones, resource blocking, or lane gates.
• Prefer the exact names and constants from the reference when explaining internals.
• If inspecting source, start with ReactFiberCommitViewTransitions.js, then follow into ReactFiberViewTransitionComponent.js, ReactFiberConfigDOM.js, ReactFiberApplyGesture.js, and ReactFiberWorkLoop.js.