wip

Author: rickhanlonii

src/content/blog/2025/04/23/react-labs-view-transitions-activity-and-more.md

@@ -12851,21 +12851,21 @@ When using Activity on a page that uses server-side rendering (SSR), there are a
 
 If part of the page is rendered with `mode="hidden"`, then it will not be included in the SSR response. Instead, React will schedule a client render for the content inside Activity while the rest of the page hydrates, prioritizing the visible content on screen.
 
-For parts of the UI rendered with `mode="visible"`, React will de-prioirtize hydration of content within Activity, similar to how Suspense content is hydrated at a lower priority. If the user interacts with the page, we'll priorize hydration within the boundary if needed.
+For parts of the UI rendered with `mode="visible"`, React will de-prioritize hydration of content within Activity, similar to how Suspense content is hydrated at a lower priority. If the user interacts with the page, we'll prioritize hydration within the boundary if needed.
 
 These are advanced use cases, but they show the additional benefits considered with Activity.
 
 ### Future modes for Activity {/*future-modes-for-activity*/}
 
-In the future, we may add more modes to Activity. 
+In the future, we may add more modes to Activity.
 
-For example, a common use case is rendering a modal, where the previous "inactive" page is visible behind the "active" modal view. The "hidden" mode does not work for this use case, because it's not visible, and not included in SSR. 
+For example, a common use case is rendering a modal, where the previous "inactive" page is visible behind the "active" modal view. The "hidden" mode does not work for this use case because it's not visible and not included in SSR.
 
-Instead, we're considering a new mode which would keep the content visible, including rendering it during SSR, but keep it unmounted and de-prioritize updates. This mode may also need to "pause" DOM updates, since it can be distracting to see backgrounded content updating while a modal is open. 
+Instead, we're considering a new mode that would keep the content visible—and included in SSR—but keep it unmounted and de-prioritize updates. This mode may also need to "pause" DOM updates, since it can be distracting to see backgrounded content updating while a modal is open.
 
-Another mode we're considering for Activity is the ability to automatically destroy state for hidden Activities if there is too much memory being used. Since the component is already unmounted, it may be preferable to destroy state for the least recently used hidden parts of the app, rather than consume too many resources. 
+Another mode we're considering for Activity is the ability to automatically destroy state for hidden Activities if there is too much memory being used. Since the component is already unmounted, it may be preferable to destroy state for the least recently used hidden parts of the app rather than consume too many resources.
 
-These are areas we're still exporing, and we'll share more as we make progress. For more information on what Activity includes today, [check out the docs](/reference/react/Activity).
+These are areas we're still exploring, and we'll share more as we make progress. For more information on what Activity includes today, [check out the docs](/reference/react/Activity).
 
 ---
 

src/content/reference/react/Activity.md

@@ -48,19 +48,10 @@ import {unstableActivity as Activity} from 'react';
 </Activity>
 ```
 
-When "hidden", the `children` of `<Activity />` are not visible on the page. If a new `<Activity>` mounts as "hidden" then it pre-renders the content at lower priority without blocking the visible content on the page, but does not mount by creating effects. When a "visible" Activity switches to "hidden" it conceptually unmounts by destroying all the effects, but saves it's state. This allows fast switching between "visible" and "hidden" states without re-creating the state for a "hidden" Activity.
+When "hidden", the `children` of `<Activity />` are not visible on the page. If a new `<Activity>` mounts as "hidden" then it pre-renders the content at lower priority without blocking the visible content on the page, but it does not mount by creating Effects. When a "visible" Activity switches to "hidden" it conceptually unmounts by destroying all the Effects, but saves its state. This allows fast switching between "visible" and "hidden" states without recreating the state for a "hidden" Activity.
 
 In the future, "hidden" Activities may automatically destroy state based on resources like memory.
 
-
-<DeepDive>
-
-#### How does `<Acivity>` work? {/*how-does-activity-work*/}
-
-Under the hood...
-
-</DeepDive>
-
 #### Props {/*props*/}
 
 * `children`: The actual UI you intend to render.
@@ -69,7 +60,7 @@ Under the hood...
 #### Caveats {/*caveats*/}
 
 - While hidden, the `children` of `<Activity>` are hidden on the page. 
-- `<Activity>` will unmount all Effects when switching from "visible" to "hidden" without destroying React or DOM state. This means Effects that expect to only run "once" on "mount" will run again when switching from "hidden" to "visible". Conceptually, "hidden" Activities are unmounted, but they are not destroyed either. We recommend using [`<StrictMode>`](/reference/react/StrictMode) to catch any unexpected side-effects from this behavior.
+- `<Activity>` will unmount all Effects when switching from "visible" to "hidden" without destroying React or DOM state. This means Effects that are expected to run only once on mount will run again when switching from "hidden" to "visible". Conceptually, "hidden" Activities are unmounted, but they are not destroyed either. We recommend using [`<StrictMode>`](/reference/react/StrictMode) to catch any unexpected side-effects from this behavior.
 - When used with `<ViewTransition>`, hidden activities that reveal in a transition will activate an "enter" animation. Visible Activities hidden in a transition will activate an "exit" animation.
 - Parts of the UI wrapped in `<Activity mode="hidden">` are not included in the SSR response.
 - Parts of the UI wrapped in `<Activity mode="visible">` will hydrate at a lower priority than other content.
@@ -88,7 +79,7 @@ You can pre-render part of the UI using `<Activity mode="hidden">`:
 </Activity>
 ```
 
-When an Activity is rendered with `mode` "hidden"`, the `children` are not visible on the page, but are rendered at lower prioirty than the visible content on the page. 
+When an Activity is rendered with `mode="hidden"`, the `children` are not visible on the page, but are rendered at lower priority than the visible content on the page. 
 
 When the `mode` later switches to "visible", the pre-rendered children will mount and become visible. This can be used to prepare parts of the UI the user is likely to interact with next to reduce loading times.
 
@@ -488,7 +479,7 @@ You can keep state for parts of the UI by switching `<Activity>` from "visible"
 </Activity>
 ```
 
-When an Activity switches from `mode` "visible"` to`"hidden", the `children` will become hidden on the page, and unmount by destroying all Effects, but will keep their React and DOM state.
+When an Activity switches from `mode="visible"` to "hidden", the `children` will become hidden on the page, and unmount by destroying all Effects, but will keep their React and DOM state.
 
 When the `mode` later switches to "visible", the saved state will be re-used when mounting the children by creating all the Effects. This can be used to keep state in parts of the UI the user is likely to interact with again to maintain DOM or React state.
 
@@ -685,7 +676,7 @@ b { display: inline-block; margin-right: 10px; }
 
 </Sandpack>
 
-This experience results in losing DOM state the user has input. We can keep the state for the Contact tab by hiding the inactive Tabs with `<Activity>`:
+This results in losing DOM state the user has input. We can keep the state for the Contact tab by hiding the inactive Tabs with `<Activity>`:
 
 
 <Sandpack>
@@ -1048,7 +1039,7 @@ video { width: 300px; margin-top: 10px; }
 
 </Sandpack>
 
-This is similar to what would happen if Activity mounted effects when hidden. Similarly, if Activity didn't unmount effects when hiding, the videos would continue to play in the background.
+This is similar to what would happen if Activity mounted Effects when hidden. Similarly, if Activity didn't unmount Effects when hiding, the videos would continue to play in the background.
 
 Activity solves this by not creating Effects when first rendered as "hidden" and destroying all Effects when switching from "visible" to "hidden":
 

src/content/reference/react/ViewTransition.md

@@ -53,7 +53,7 @@ By default, `<ViewTransition>` animates with a smooth cross-fade (the browser de
 
 #### How does `<ViewTransition>` work? {/*how-does-viewtransition-work*/}
 
-Under the hood, React applies `view-transition-name` to inline styles of the nearest DOM node nested inside the `<ViewTransition>` component. If there are multiple siblings DOM nodes like `<ViewTransition><div /><div /></ViewTransition>` then React adds a suffix to the name to make each unique but conceptually they're part of the same one. React doesn't apply these eagerly but only at the time that boundary should participate in an animation.
+Under the hood, React applies `view-transition-name` to inline styles of the nearest DOM node nested inside the `<ViewTransition>` component. If there are multiple sibling DOM nodes like `<ViewTransition><div /><div /></ViewTransition>` then React adds a suffix to the name to make each unique but conceptually they're part of the same one. React doesn't apply these eagerly but only at the time that boundary should participate in an animation.
 
 React automatically calls `startViewTransition` itself behind the scenes so you should never do that yourself. In fact, if you have something else on the page running a ViewTransition React will interrupt it. So it's recommended that you use React itself to coordinate these. If you had other ways of trigger ViewTransitions in the past, we recommend that you migrate to the built-in way.
 
@@ -67,7 +67,7 @@ Then React calls `startViewTransition`. Inside the `updateCallback`, React will:
 - Wait for fonts to load.
 - Call componentDidMount, componentDidUpdate, useLayoutEffect and refs.
 - Wait for any pending Navigation to finish.
-- Then React will measure any changes to the layout to see which boundaries will need to animation.
+- Then React will measure any changes to the layout to see which boundaries will need to animate.
 
 After the ready Promise of the `startViewTransition` is resolved, React will then revert the `view-transition-name`. Then React will invoke the `onEnter`, `onExit`, `onUpdate` and `onShare` callbacks to allow for manual programmatic control over the Animations. This will be after the built-in default ones have already been computed.
 
@@ -94,7 +94,7 @@ These callbacks allow you to adjust the animation imperatively using the [animat
 
 * **optional** `onEnter`: A function. React calls `onEnter` after an "enter" animation.
 * **optional** `onExit`: A function. React calls `onExit` after an "exit" animation.
-* **optional** `onShare`:  A function. React calls `onShare` after an "share" animation.
+* **optional** `onShare`:  A function. React calls `onShare` after a "share" animation.
 * **optional** `onUpdate`:  A function. React calls `onUpdate` after an "update" animation.
 
 Each callback receives as arguments:
@@ -113,7 +113,7 @@ The value `'none'` can be used to prevent a View Transition from activating for
 
 <Note>
 
-In many early examples of View Transitions around the web you'll have seen using a [`view-transition-name`](https://developer.mozilla.org/en-US/docs/Web/CSS/view-transition-name) and then style it using `::view-transition-...(my-name)` selectors. We don't recommend that for styling. Instead, we normally recommend using a View Transition Class instead.
+In many early examples of View Transitions around the web, you'll have seen using a [`view-transition-name`](https://developer.mozilla.org/en-US/docs/Web/CSS/view-transition-name) and then style it using `::view-transition-...(my-name)` selectors. We don't recommend that for styling. Instead, we normally recommend using a View Transition Class instead.
 
 </Note>
 
@@ -1308,14 +1308,14 @@ Enter/Exit:
 </Suspense>
 ```
 
-In this scenario, these are two separate ViewTransition instances each with their own `view-transition-name`. This will be treated as an "exit" of the `<A>` and an "enter of the `<B>`.
+In this scenario, these are two separate ViewTransition instances each with their own `view-transition-name`. This will be treated as an "exit" of the `<A>` and an "enter" of the `<B>`.
 
 You can achieve different effects depending on where you choose to place the `<ViewTransition>` boundary.
 
 ---
 ### Opting-out of an animation {/*opting-out-of-an-animation*/}
 
-Sometimes you're wrapping a large existing component, like a whole page, and you want to animate some updates to, such as changing the theme. However, you don't want it to opt-in all updates inside the whole page to cross-fade when they're updating. Especially if you're incrementally adding more animations.
+Sometimes you're wrapping a large existing component, like a whole page, and you want to animate some updates, such as changing the theme. However, you don't want it to opt-in all updates inside the whole page to cross-fade when they're updating. Especially if you're incrementally adding more animations.
 
 You can use the class "none" to opt-out of an animation. By wrapping your children in a "none" you can disable animations for updates to them while the parent still triggers.
 

src/sidebarBlog.json

@@ -11,6 +11,13 @@
       "path": "/blog",
       "skipBreadcrumb": true,
       "routes": [
+        {
+          "title": "React Labs: View Transitions, Activity, and more",
+          "titleForHomepage": "View Transitions and Activity",
+          "icon": "blog",
+          "date": "April 23, 2025",
+          "path": "/blog/2025/04/23/react-labs-view-transitions-activity-and-more"
+        },
         {
           "title": "React Compiler RC",
           "titleForHomepage": "React Compiler RC",