From e8947d72f7f8df543010a25796a665c43ed60408 Mon Sep 17 00:00:00 2001 From: Bartosz Kaszubowski Date: Fri, 12 Sep 2025 10:16:21 +0200 Subject: [PATCH] address website build warnings --- docs/_getting-started-macos-android.md | 2 +- website/blog/2020-07-06-version-0.63.md | 2 +- ...2024-10-23-the-new-architecture-is-here.md | 54 +++++++++---------- ...-moving-towards-a-stable-javascript-api.md | 48 ++++++++--------- 4 files changed, 53 insertions(+), 53 deletions(-) diff --git a/docs/_getting-started-macos-android.md b/docs/_getting-started-macos-android.md index 59083bcd718..2784423c780 100644 --- a/docs/_getting-started-macos-android.md +++ b/docs/_getting-started-macos-android.md @@ -65,7 +65,7 @@ Setting up your development environment can be somewhat tedious if you're new to Then, click "Next" to install all of these components. -::note +:::note If the checkboxes are grayed out, you will have a chance to install these components later on. ::: diff --git a/website/blog/2020-07-06-version-0.63.md b/website/blog/2020-07-06-version-0.63.md index 0248d05df09..d62ce81f8e2 100644 --- a/website/blog/2020-07-06-version-0.63.md +++ b/website/blog/2020-07-06-version-0.63.md @@ -136,7 +136,7 @@ At the same time, we are dropping support for Node 8. [Its LTS maintenance cycle Thank you to the hundreds of contributors that helped make 0.63 possible! -::note +:::note Special thanks to [Rick Hanlon](https://twitter.com/rickhanlonii) for authoring the section on `LogBox` and [Eli White](https://twitter.com/Eli_White) for authoring the `Pressable` part of this article. ::: diff --git a/website/blog/2024-10-23-the-new-architecture-is-here.md b/website/blog/2024-10-23-the-new-architecture-is-here.md index 470eb51584e..9207136de2a 100644 --- a/website/blog/2024-10-23-the-new-architecture-is-here.md +++ b/website/blog/2024-10-23-the-new-architecture-is-here.md @@ -230,17 +230,17 @@ Separating urgent events from transitions allows for a more responsive user inte Here's a comparison of the old architecture without transitions and the new architecture with transitions. Imagine that each tile isn't a trivial view with a background color, but a rich component containing images and other components that are expensive to render. **After** using `useTransition` you avoid thrashing your app with updates and falling behind.
-
- A video demonstrating an app rendering many views (tiles) according to a slider input. The views are rendered in batches as the slider is quickly adjusted from 0 to 1000. -
Before: rendering tiles without marking it as a transition.
-
-
- A video demonstrating an app rendering many views (tiles) according to a slider input. The views are rendered in batches as the slider is quickly adjusted from 0 to 1000. There are less batch renders in comparison to the next video. -
After: rendering tiles with transitions to interrupt in-progress renders of stale state.
-
+
+ A video demonstrating an app rendering many views (tiles) according to a slider input. The views are rendered in batches as the slider is quickly adjusted from 0 to 1000. +
Before: rendering tiles without marking it as a transition.
+
+
+ A video demonstrating an app rendering many views (tiles) according to a slider input. The views are rendered in batches as the slider is quickly adjusted from 0 to 1000. There are less batch renders in comparison to the next video. +
After: rendering tiles with transitions to interrupt in-progress renders of stale state.
+
-For more information, see [Support for Concurrent Renderer and Features](/docs/0.75/the-new-architecture/landing-page#support-for-concurrent-renderer-and-features). +For more information, see [Support for Concurrent Renderer and Features](/architecture/landing-page#support-for-concurrent-renderer-and-features). ### Automatic Batching @@ -249,19 +249,19 @@ When upgrading to the New Architecture, you will benefit from automatic batching Automatic batching allows React to batch together more state updates when rendering to avoid the rendering of intermediate states. This allows React Native to be faster and less susceptible to lags, without any additional code from the developer.
-
- A video demonstrating an app rendering many views according to a slider input. The slider value is adjusted from 0 to 1000 and the UI slowly catches up to rendering 1000 views. -
Before: rendering frequent state updates with legacy renderer.
-
-
- A video demonstrating an app rendering many views according to a slider input. The slider value is adjusted from 0 to 1000 and the UI resolves to 1000 views faster than the previous example, without as many intermediate states. -
After: rendering frequent state updates with automatic batching.
-
+
+ A video demonstrating an app rendering many views according to a slider input. The slider value is adjusted from 0 to 1000 and the UI slowly catches up to rendering 1000 views. +
Before: rendering frequent state updates with legacy renderer.
+
+
+ A video demonstrating an app rendering many views according to a slider input. The slider value is adjusted from 0 to 1000 and the UI resolves to 1000 views faster than the previous example, without as many intermediate states. +
After: rendering frequent state updates with automatic batching.
+
In the old architecture, more intermediate states are rendered, and the UI keeps updating even when the slider stops moving. The New Architecture, renders fewer intermediate states and completes the rendering much sooner thanks to automatically batching the updates. -For more information, see [Support for Concurrent Renderer and Features](/docs/0.75/the-new-architecture/landing-page#support-for-concurrent-renderer-and-features). +For more information, see [Support for Concurrent Renderer and Features](/architecture/landing-page#support-for-concurrent-renderer-and-features). ### useLayoutEffect @@ -303,14 +303,14 @@ useLayoutEffect(() => { This change allows you to read layout information synchronously and update the UI in the same frame, allowing you to position elements correctly before they are displayed to the user:
-
- A view that is moving to the corners of the viewport and center with a tooltip rendered either above or below it. The tooltip is rendered after a short delay after the view moves -
In the old architecture, layout was read asynchronously in `onLayout`, causing the position of the tooltip to be delayed.
-
-
- A view that is moving to the corners of the viewport and center with a tooltip rendered either above or below it. The view and tooltip move in unison. -
In the New Architecture, layout can be read in `useLayoutEffect` synchronously, updating the tooltip position before displaying.
-
+
+ A view that is moving to the corners of the viewport and center with a tooltip rendered either above or below it. The tooltip is rendered after a short delay after the view moves +
In the old architecture, layout was read asynchronously in `onLayout`, causing the position of the tooltip to be delayed.
+
+
+ A view that is moving to the corners of the viewport and center with a tooltip rendered either above or below it. The view and tooltip move in unison. +
In the New Architecture, layout can be read in `useLayoutEffect` synchronously, updating the tooltip position before displaying.
+
For more information, see the docs for [Synchronous Layout and Effects](/docs/0.75/the-new-architecture/landing-page#synchronous-layout-and-effects). @@ -379,7 +379,7 @@ If, for any reason, the New Architecture is not behaving properly in your applic To opt-out from the New Architecture: -- On Android, modify the `android/gradle.properties` file and turn off the `newArchEnabled` flag +- On Android, modify the `android/gradle.properties` file and turn off the `newArchEnabled` flag: ```diff title=”gradle.properties” -newArchEnabled=true diff --git a/website/blog/2025-06-12-moving-towards-a-stable-javascript-api.md b/website/blog/2025-06-12-moving-towards-a-stable-javascript-api.md index ed2d59b63b8..d9140e502d3 100644 --- a/website/blog/2025-06-12-moving-towards-a-stable-javascript-api.md +++ b/website/blog/2025-06-12-moving-towards-a-stable-javascript-api.md @@ -5,7 +5,7 @@ tags: [announcement] date: 2025-06-12T16:00 --- -In React Native 0.80, we're introducing two significant changes to React Native's JavaScript API — the deprecation of deep imports, and our new Strict TypeScript API. These are part of an ongoing effort to accurately define our API and offer dependable type safety to users and frameworks. +In React Native 0.80, we're introducing two significant changes to React Native's JavaScript API — the deprecation of deep imports, and our new Strict TypeScript API. These are part of an ongoing effort to accurately define our API and offer dependable type safety to users and frameworks. **Quick takeaways:** @@ -17,13 +17,13 @@ In React Native 0.80, we're introducing two significant changes to React Native' ## What's changing and why -We are moving to improve and stabilise React Native's public JavaScript API — i.e. what you get when you import `'react-native'`. +We are moving to improve and stabilise React Native's public JavaScript API — i.e. what you get when you import `'react-native'`. -Historically, we've approximated this. React Native is authored in [Flow](https://flow.org/), but the community has long since moved to TypeScript in open source, which is how the public API is consumed and validated for compatibility. Our types have been (lovingly) [community-contributed](https://www.npmjs.com/package/@types/react-native), and since merged and aligned in our codebase. However, these have relied on manual maintenance and no automated tooling, introducing correctness gaps. +Historically, we've approximated this. React Native is authored in [Flow](https://flow.org/), but the community has long since moved to TypeScript in open source, which is how the public API is consumed and validated for compatibility. Our types have been (lovingly) [community-contributed](https://www.npmjs.com/package/@types/react-native), and since merged and aligned in our codebase. However, these have relied on manual maintenance and no automated tooling, introducing correctness gaps. -Additionally, our public JS API has been poorly defined in terms of module boundaries — e.g. internal `'react-native/Libraries/'` deep imports were reachable by app code, but could frequently change as we updated these internals. +Additionally, our public JS API has been poorly defined in terms of module boundaries — e.g. internal `'react-native/Libraries/'` deep imports were reachable by app code, but could frequently change as we updated these internals. -In 0.80, we're addressing these issues by deprecating deep imports, and introducing a user opt-in to a new, generated API baseline in TypeScript. We're calling this our **Strict TypeScript API**. Ultimately, this is the groundwork to offer a stable React Native API in future. +In 0.80, we're addressing these issues by deprecating deep imports, and introducing a user opt-in to a new, generated API baseline in TypeScript. We're calling this our **Strict TypeScript API**. Ultimately, this is the groundwork to offer a stable React Native API in the future. ## Deprecating deep imports from `react-native` @@ -131,12 +131,12 @@ npx expo start --clear ## Strict TypeScript API (opt-in) -The Strict TypeScript API is a new set of TypeScript types in the `react-native` package, which can be opted into via your `tsconfig.json`. We're shipping these alongside our existing TS types, meaning you can choose to migrate when ready. +The Strict TypeScript API is a new set of TypeScript types in the `react-native` package, which can be opted into via your `tsconfig.json`. We're shipping these alongside our existing TS types, meaning you can choose to migrate when ready. The new types are: -1. **Generated directly from our source code** — improving coverage and correctness, so you can expect stronger compatibility guarantees. -2. **Restricted to `react-native`'s index file** — more tightly defining our public API, and meaning we won't break the API when making internal file changes. +1. **Generated directly from our source code** — improving coverage and correctness, so you can expect stronger compatibility guarantees. +2. **Restricted to `react-native`'s index file** — more tightly defining our public API, and meaning we won't break the API when making internal file changes. When the community is ready, the Strict TypeScript API will become our default API in future — synchronized with deep imports removal. This means it's a **good idea** to begin opting in, as you'll be ready for React Native's future stable JS API. @@ -178,7 +178,7 @@ We've scoped our public API to the exports of React Native's `index.js` file, wh Types are now generated from source, rather than manually maintained. In doing this: -- We've aligned differences that had built up from the community contributed types — and also increased the type coverage of our source code. +- We've aligned differences that had built up from the community contributed types — and also increased the type coverage of our source code. - We've intentionally updated some type names and type shapes, where there was scope to simplify or reduce ambiguity. :::tip Key win @@ -225,7 +225,7 @@ Please refer to our [dedicated guide](/docs/strict-typescript-api) in the docs w We appreciate that any breaking change to React Native will take time for developers to update to in their apps. -#### Now — Opt-in launch (0.80) +#### Now — Opt-in launch (0.80) The `"react-native-strict-api"` opt-in is stable in the 0.80 release. @@ -235,13 +235,13 @@ The `"react-native-strict-api"` opt-in is stable in the 0.80 release. :::tip Recommended -The Strict TypeScript API will become our default API in future. +The Strict TypeScript API will become our default API in the future. -If you have time, it's worth testing the opt-in now in your `tsconfig.json`, to futureproof your app or library. This will immediately evaluate if there are any type errors introduced in your app under the Strict API. **There may be none(!)** — in which case, you're good to go. +If you have time, it's worth testing the opt-in now in your `tsconfig.json`, to futureproof your app or library. This will immediately evaluate if there are any type errors introduced in your app under the Strict API. **There may be none(!)** — in which case, you're good to go. ::: -#### Future — Strict TypeScript API by default +#### Future — Strict TypeScript API by default In the future, we will require all codebases to use our Strict API, and will remove the legacy types. @@ -304,17 +304,17 @@ Thanks also to [Pieter Vanderwerff](https://github.com/pieterv), [Rubén Norte]( :::note Learn more -
-

-Watch the talk! -We shared a deep dive into our motivations and the work behind the Strict TypeScript API at App.js 2025. -**[View on YouTube](https://www.youtube.com/live/UTaJlqhTk2g?si=SDRmj80kss7hXuGG&t=6520)** -

-App.js 2025 Talk +
+
+ Watch the talk! + We shared a deep dive into our motivations and the work behind the Strict TypeScript API at App.js 2025. +

**[View on YouTube](https://www.youtube.com/live/UTaJlqhTk2g?si=SDRmj80kss7hXuGG&t=6520)**

+
+ App.js 2025 Talk
:::