Skip to content

address website build warnings #4796

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
Simek merged 1 commit into from
Sep 12, 2025
Merged

address website build warnings #4796

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion docs/_getting-started-macos-android.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.
:::

Expand Down
2 changes: 1 addition & 1 deletion website/blog/2020-07-06-version-0.63.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.
:::

Expand Down
54 changes: 27 additions & 27 deletions website/blog/2024-10-23-the-new-architecture-is-here.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.

<div className="TwoColumns TwoFigures">
<figure>
<img src="/img/new-architecture/without-transitions.gif" alt="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." />
<figcaption><b>Before:</b> rendering tiles without marking it as a transition.</figcaption>
</figure>
<figure>
<img src="/img/new-architecture/with-transitions.gif" alt="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." />
<figcaption><b>After:</b> rendering tiles <em>with transitions</em> to interrupt in-progress renders of stale state.</figcaption>
</figure>
<figure>
<img src="/img/new-architecture/without-transitions.gif" alt="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." />
<figcaption><b>Before:</b> rendering tiles without marking it as a transition.</figcaption>
</figure>
<figure>
<img src="/img/new-architecture/with-transitions.gif" alt="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." />
<figcaption><b>After:</b> rendering tiles <em>with transitions</em> to interrupt in-progress renders of stale state.</figcaption>
</figure>
</div>

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

Expand All @@ -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.

<div className="TwoColumns TwoFigures">
<figure>
<img src="/img/new-architecture/legacy-renderer.gif" alt="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." />
<figcaption><b>Before:</b> rendering frequent state updates with legacy renderer.</figcaption>
</figure>
<figure>
<img src="/img/new-architecture/react18-renderer.gif" alt="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." />
<figcaption><b>After:</b> rendering frequent state updates with <em>automatic batching</em>.</figcaption>
</figure>
<figure>
<img src="/img/new-architecture/legacy-renderer.gif" alt="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." />
<figcaption><b>Before:</b> rendering frequent state updates with legacy renderer.</figcaption>
</figure>
<figure>
<img src="/img/new-architecture/react18-renderer.gif" alt="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." />
<figcaption><b>After:</b> rendering frequent state updates with <em>automatic batching</em>.</figcaption>
</figure>
</div>

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

Expand Down Expand Up @@ -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:

<div className="TwoColumns TwoFigures">
<figure>
<img src="/img/new-architecture/async-on-layout.gif" alt="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" />
<figcaption>In the old architecture, layout was read asynchronously in `onLayout`, causing the position of the tooltip to be delayed.</figcaption>
</figure>
<figure>
<img src="/img/new-architecture/sync-use-layout-effect.gif" alt="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." />
<figcaption>In the New Architecture, layout can be read in `useLayoutEffect` synchronously, updating the tooltip position before displaying.</figcaption>
</figure>
<figure>
<img src="/img/new-architecture/async-on-layout.gif" alt="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" />
<figcaption>In the old architecture, layout was read asynchronously in `onLayout`, causing the position of the tooltip to be delayed.</figcaption>
</figure>
<figure>
<img src="/img/new-architecture/sync-use-layout-effect.gif" alt="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." />
<figcaption>In the New Architecture, layout can be read in `useLayoutEffect` synchronously, updating the tooltip position before displaying.</figcaption>
</figure>
</div>

For more information, see the docs for [Synchronous Layout and Effects](/docs/0.75/the-new-architecture/landing-page#synchronous-layout-and-effects).
Expand Down Expand Up @@ -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
Expand Down
48 changes: 24 additions & 24 deletions website/blog/2025-06-12-moving-towards-a-stable-javascript-api.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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:**

Expand All @@ -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`

Expand Down Expand Up @@ -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.

Expand Down Expand Up @@ -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
Expand Down Expand Up @@ -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.

Expand All @@ -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.

Expand Down Expand Up @@ -304,17 +304,17 @@ Thanks also to [Pieter Vanderwerff](https://github.com/pieterv), [Rubén Norte](

:::note Learn more

<div style={{display: 'flex'}}>
<p style={{flex: 1, marginRight: 40, marginBottom: 0}}>
<strong style={{ display: 'block', marginTop: 8, marginBottom: 8 }}>Watch the talk!</strong>
<span style={{ display: 'block', marginBottom: 8 }}>We shared a deep dive into our motivations and the work behind the Strict TypeScript API at <strong>App.js 2025</strong>.</span>
**[View on YouTube](https://www.youtube.com/live/UTaJlqhTk2g?si=SDRmj80kss7hXuGG&t=6520)**
</p>
<img
src="/blog/assets/0.80-js-stable-api-appjs.jpg"
style={{ flexShrink: 0, width: '200px', aspectRatio: '16/9', objectFit: 'contain' }}
alt="App.js 2025 Talk"
/>
<div style={{ display: 'flex', alignItems: 'center', gap: 40 }}>
<div style={{ flex: 1 }}>
<strong style={{ display: 'block', marginTop: 8, marginBottom: 8 }}>Watch the talk!</strong>
<span style={{ display: 'block', marginBottom: 8 }}>We shared a deep dive into our motivations and the work behind the Strict TypeScript API at <strong>App.js 2025</strong>.</span>
<p style={{ marginBottom: 8 }}>**[View on YouTube](https://www.youtube.com/live/UTaJlqhTk2g?si=SDRmj80kss7hXuGG&t=6520)**</p>
</div>
<img
src="/blog/assets/0.80-js-stable-api-appjs.jpg"
style={{ flexShrink: 0, maxWidth: '200px', aspectRatio: '16/9', borderRadius: 10 }}
alt="App.js 2025 Talk"
/>
</div>

:::