View transitions
LayoutId animates elements that exist on both sides of a change. The browser's
native View Transitions API handles the case where they do not: it snapshots
the page before and after, then cross-fades the two. That makes it the right tool when a change
is wholesale - a whole panel replaced, a route swapped - and LayoutId the right
tool when one specific thing moves.
Wrapping a state change
BmotionViewTransition.StartAsync puts
document.startViewTransition around a Blazor state change: your callback
mutates state and calls StateHasChanged, and the browser handles the rest.
Elements that carry a view-transition-name get their own snapshot pair and can
be animated individually in CSS. Where the API is unsupported the state change simply
applies without a transition - there is no fallback to write.
Overview
A high-level tour. Switching tabs cross-fades this panel via the native View Transitions API - the panel is replaced outright, so there is no element for a FLIP to follow.
Choosing between the two
They are complements, not competitors, and they can run in the same app on the same screen.
- LayoutId (FLIP) - one element persists across the change and you want it to travel. Runs in C#, works in every browser Blazor does, and is interruptible mid-flight.
- View transitions - the content is replaced wholesale and a cross-fade is the honest description of what happened. Costs almost no code, but the animation is the browser's and only runs where the API exists.