mirror of
https://github.com/zebrajr/react.git
synced 2025-12-06 00:20:04 +01:00
6a8c7fb6f1
## Overview This PR ships the View Transition APIs to `react@canary`: - [`<ViewTransition />`](https://react.dev/reference/react/ViewTransition) - [`addTransitionType`](https://react.dev/reference/react/addTransitionType) This means these APIs are ready for final feedback and prepare for semver stable release. ## What this means Shipping `<ViewTransition />` and `addTransitionType` to canary means they have gone through extensive testing in production, we are confident in the stability of the APIs, and we are preparing to release it in a future semver stable version. Libraries and frameworks following the [Canary Workflow](https://react.dev/blog/2023/05/03/react-canaries) should begin implementing and testing these features. ## Why we follow the Canary Workflow To prepare for semver stable, libraries should test canary features like `<ViewTransition />` with `react@canary` to confirm compatibility and prepare for the next semver release in a myriad of environments and configurations used throughout the React ecosystem. This provides libraries with ample time to catch any issues we missed before slamming them with problems in the wider semver release. Since these features have already gone through extensive production testing, and we are confident they are stable, frameworks following the [Canary Workflow](https://react.dev/blog/2023/05/03/react-canaries) can also begin adopting canary features like `<ViewTransition />`. This adoption is similar to how different Browsers implement new proposed browser features before they are added to the standard. If a frameworks adopts a canary feature, they are committing to stability for their users by ensuring any API changes before a semver stable release are opaque and non-breaking to their users. Apps not using a framework are also free to adopt canary features like `<ViewTransition>` as long as they follow the [Canary Workflow](https://react.dev/blog/2023/05/03/react-canaries), but we generally recommend waiting for a semver stable release unless you have the capacity to commit to following along with the canary changes and debugging library compatibility issues. Waiting for semver stable means you're able to benefit from libraries testing and confirming support, and use semver as signal for which version of a library you can use with support of the feature. ## Docs Check out the ["React Labs: View Transitions, Activity, and more"](https://react.dev/blog/2025/04/23/react-labs-view-transitions-activity-and-more#view-transitions) blog post, and [the new docs for `<ViewTransition />`](https://react.dev/reference/react/ViewTransition) and [`addTransitionType`](https://react.dev/reference/react/addTransitionType) for more info. |
||
|---|---|---|
| .. | ||
| loader | ||
| public | ||
| server | ||
| src | ||
| package.json | ||
| README.md | ||
| yarn.lock | ||
View Transition
A test case for View Transitions.
Setup
To reference a local build of React, first run npm run build at the root
of the React project. Then:
cd fixtures/view-transition
yarn
yarn start
The start command runs a webpack dev server and a server-side rendering server in development mode with hot reloading.
Note: whenever you make changes to React and rebuild it, you need to re-run yarn in this folder:
yarn
If you want to try the production mode instead run:
yarn start:prod
This will pre-build all static resources and then start a server-side rendering HTTP server that hosts the React app and service the static resources (without hot reloading).