新しいアーキテクチャが登場

2024年10月23日 ·24分で読めます

The React Team

@reactjs / @reactnative

新アーキテクチャがデフォルトになったReact Native 0.76がnpmで利用可能になりました！

0.76リリースのブログ記事では、このバージョンに含まれる重要な変更点のリストを共有しました。この記事では、新アーキテクチャの概要と、それがReact Nativeの未来をどのように形作るかについて説明します。

新アーキテクチャは、Suspense、Transitions、自動バッチ処理、useLayoutEffectといった最新のReact機能を完全にサポートします。また、新しいネイティブモジュールとネイティブコンポーネントシステムも含まれており、これによりブリッジを介さずにネイティブインターフェースに直接アクセスできる、型安全なコードを書くことができます。

このリリースは、2018年から取り組んできたReact Nativeのゼロからの書き直しによる成果であり、ほとんどのアプリにとって新アーキテクチャへの移行が段階的に行えるよう細心の注意を払いました。2021年には、Reactエコシステム全体のスムーズなアップグレード体験を確実にするため、コミュニティと協力するための新アーキテクチャワーキンググループを設立しました。

ほとんどのアプリは、他のリリースと同じレベルの労力でReact Native 0.76を導入できます。最も人気のあるReact Nativeライブラリは、すでに新アーキテクチャをサポートしています。新アーキテクチャには、旧アーキテクチャをターゲットとするライブラリとの後方互換性を可能にする自動相互運用性レイヤーも含まれています。

過去数年間の開発を通じて、私たちのチームは新アーキテクチャのビジョンを公に共有してきました。これらの講演を見逃した方は、こちらでご確認ください。

新アーキテクチャとは

新アーキテクチャは、React Nativeを支える主要なシステムを完全に書き直したものです。これには、コンポーネントのレンダリング方法、JavaScriptの抽象化がネイティブの抽象化と通信する方法、そして異なるスレッド間で作業がスケジュールされる方法などが含まれます。ほとんどのユーザーはこれらのシステムがどのように機能するかを考える必要はありませんが、これらの変更は改善と新しい機能をもたらします。

旧アーキテクチャでは、React Nativeは非同期ブリッジを使用してネイティブプラットフォームと通信していました。コンポーネントをレンダリングしたり、ネイティブ関数を呼び出したりするには、React Nativeはネイティブ関数の呼び出しをブリッジでシリアライズしてキューに入れる必要があり、それは非同期に処理されていました。このアーキテクチャの利点は、すべての作業がバックグラウンドスレッドで行われるため、レンダリング更新やネイティブモジュールの関数呼び出し処理でメインスレッドがブロックされることがなかった点です。

しかし、ユーザーはネイティブアプリのような感覚を得るために、インタラクションに対する即時のフィードバックを期待します。これは、一部の更新はユーザー入力に応じて同期的にレンダリングされる必要があり、進行中のレンダリングを中断する可能性があることを意味します。旧アーキテクチャは非同期のみであったため、非同期と同期の両方の更新を可能にするために書き直す必要がありました。

さらに、旧アーキテクチャでは、ブリッジを介した関数呼び出しのシリアライズは、特に頻繁な更新や大きなオブジェクトの場合にすぐにボトルネックとなりました。これにより、アプリが安定して60+ FPSを達成することが困難でした。また、同期の問題もありました。JavaScriptとネイティブレイヤーが非同期になると、それらを同期的に調整することが不可能になり、リストが空のスペースのフレームを表示したり、中間状態がレンダリングされることによる視覚的なUIのジャンプなどのバグが発生しました。

最後に、旧アーキテクチャはネイティブ階層を使用してUIの単一のコピーを保持し、そのコピーを直接変更していたため、レイアウトは単一のスレッドでしか計算できませんでした。これにより、ユーザー入力のような緊急の更新を処理することが不可能になり、ツールチップの位置を更新するためにレイアウトエフェクトで読み込むなど、レイアウトを同期的に読み取ることができませんでした。

これらの問題はすべて、Reactの並行（concurrent）機能を適切にサポートすることが不可能であることを意味していました。これらの問題を解決するため、新アーキテクチャには4つの主要な部分が含まれています。

新しいネイティブモジュールシステム
新しいレンダラー
イベントループ
ブリッジの削除

新しいモジュールシステムにより、React Nativeレンダラーはネイティブレイヤーに同期的にアクセスできるようになり、イベントの処理、更新のスケジューリング、レイアウトの読み取りを非同期と同期の両方で行うことができます。新しいネイティブモジュールはデフォルトで遅延読み込みされるため、アプリに大幅なパフォーマンス向上をもたらします。

新しいレンダラーは、複数のスレッドにわたって進行中の複数のツリーを処理できます。これにより、Reactはメインスレッドまたはバックグラウンドスレッドで、複数の同時更新優先度を処理できます。また、複数のスレッドからのレイアウトの同期または非同期の読み取りをサポートし、ジャンクのない、より応答性の高いUIをサポートします。

新しいイベントループは、JavaScriptスレッド上のタスクを明確に定義された順序で処理できます。これにより、Reactはレンダリングを中断してイベントを処理できるため、緊急のユーザーイベントが優先度の低いUIトランジションよりも優先されます。イベントループはWeb仕様とも整合しており、マイクロタスク、MutationObserver、IntersectionObserverのようなブラウザ機能をサポートできます。

最後に、ブリッジを削除することで、起動が高速化され、JavaScriptとネイティブランタイム間の直接通信が可能になり、作業の切り替えコストが最小限に抑えられます。これにより、エラー報告、デバッグが改善され、未定義の動作によるクラッシュが減少します。

新アーキテクチャは現在、本番環境で使用する準備が整っています。MetaではFacebookアプリや他の製品で既に大規模に使用されています。私たちは、Questデバイス向けに開発したFacebookおよびInstagramアプリで、React Nativeと新アーキテクチャを成功裏に使用しました。

私たちのパートナーは、すでに数ヶ月前から新アーキテクチャを本番環境で使用しています。ExpensifyやKrakenによるこれらの成功事例をご覧いただき、Blueskyの新しいリリースもぜひお試しください。

新しいネイティブモジュール

新しいネイティブモジュールシステムは、JavaScriptとネイティブプラットフォームの通信方法を大幅に書き直したものです。これは完全にC++で書かれており、多くの新しい機能が解放されます。

ネイティブランタイムへの、またネイティブランタイムからの同期アクセス
JavaScriptとネイティブコード間の型安全性
プラットフォーム間でのコード共有
デフォルトでのモジュールの遅延読み込み

新しいネイティブモジュールシステムでは、JavaScriptとネイティブレイヤーが非同期ブリッジを使用することなく、JavaScriptインターフェース（JSI）を通じて互いに同期的に通信できるようになりました。これは、カスタムネイティブモジュールが同期的に関数を呼び出し、値を返し、その値を別のネイティブモジュール関数に渡すことができるようになったことを意味します。

旧アーキテクチャでは、ネイティブ関数の呼び出しからのレスポンスを処理するために、コールバックを提供する必要があり、返される値はシリアライズ可能である必要がありました。

// ❌ Sync callback from Native Module
nativeModule.getValue(value => {
  // ❌ value cannot reference a native object
  nativeModule.doSomething(value);
});

新アーキテクチャでは、ネイティブ関数への同期呼び出しが可能です。

// ✅ Sync response from Native Module
const value = nativeModule.getValue();

// ✅ value can be a reference to a native object
nativeModule.doSomething(value);

新アーキテクチャにより、JavaScript/TypeScript APIからアクセスしながら、C++ネイティブ実装の全能力を最終的に活用できるようになります。新しいモジュールシステムはC++で書かれたモジュールをサポートしているため、モジュールを一度書けば、Android、iOS、Windows、macOSを含むすべてのプラットフォームで動作します。モジュールをC++で実装することで、よりきめ細かいメモリ管理とパフォーマンスの最適化が可能になります。

さらに、Codegenを使用すると、モジュールはJavaScriptレイヤーとネイティブレイヤーの間で厳密に型付けされた契約を定義できます。私たちの経験上、クロスプラットフォームアプリにおけるクラッシュの最も一般的な原因の1つは、境界を越えた型エラーです。Codegenは、これらの問題を克服しつつ、ボイラープレートコードも生成してくれます。

最後に、モジュールは遅延読み込みされるようになりました。つまり、起動時ではなく、実際に必要になったときにのみメモリにロードされます。これにより、アプリの起動時間が短縮され、アプリケーションが複雑になっても起動時間を低く保つことができます。

react-native-mmkvのような人気ライブラリは、新しいネイティブモジュールへの移行による利点をすでに実感しています。

「新しいネイティブモジュールは、react-native-mmkvのセットアップ、自動リンク、初期化を大幅に簡素化しました。新アーキテクチャのおかげで、react-native-mmkvは純粋なC++ネイティブモジュールとなり、どのプラットフォームでも動作するようになりました。新しいCodegenによりMMKVは完全に型安全になり、null安全性を強制することで長年のNullPointerReferenceの問題を修正しました。また、ネイティブモジュール関数を同期的に呼び出せるようになったことで、カスタムJSIアクセスを新しいネイティブモジュールAPIに置き換えることができました。」

Marc Rousavy、react-native-mmkvの作者

新しいレンダラー

ネイティブレンダラーも完全に書き直し、いくつかの利点を追加しました。

更新は異なるスレッドで異なる優先度でレンダリングできます。
レイアウトは同期的かつ異なるスレッド間で読み取ることができます。
レンダラーはC++で書かれ、すべてのプラットフォームで共有されます。

更新されたネイティブレンダラーは、ビュー階層を不変（immutable）なツリー構造で保存するようになりました。これは、UIが直接変更できない方法で保存されることを意味し、更新のスレッドセーフな処理を可能にします。これにより、それぞれがユーザーインターフェースの異なるバージョンを表す、進行中の複数のツリーを処理できます。結果として、UIをブロックすることなく（トランジション中など）バックグラウンドで更新をレンダリングしたり、（ユーザー入力に応じて）メインスレッドでレンダリングしたりできます。

複数のスレッドをサポートすることで、Reactは優先度の低い更新を中断して、ユーザー入力によって生成されたような緊急の更新をレンダリングし、その後必要に応じて優先度の低い更新を再開できます。新しいレンダラーは、レイアウト情報を同期的かつ異なるスレッド間で読み取ることもできます。これにより、優先度の低い更新のためのバックグラウンド計算と、ツールチップの再配置など、必要な場合の同期的な読み取りが可能になります。

最後に、レンダラーをC++で書き直すことで、すべてのプラットフォームで共有できるようになります。これにより、iOS、Android、Windows、macOS、およびその他のReact Nativeがサポートするプラットフォームで同じコードが実行されることが保証され、プラットフォームごとに再実装する必要なく、一貫したレンダリング機能が提供されます。

これは、私たちのMany Platform Visionに向けた重要な一歩です。例えば、View Flatteningは深いレイアウトツリーを避けるためのAndroid専用の最適化でした。新しいレンダラーは、共有C++コアにより、この機能をiOSにもたらします。この最適化は自動であり、セットアップは不要で、共有レンダラーによって無料で提供されます。

これらの変更により、React NativeはSuspenseやTransitionsのようなConcurrent Reactの機能を完全にサポートし、ジャンク、遅延、視覚的なジャンプなしにユーザー入力に迅速に反応する複雑なユーザーインターフェースを構築することが容易になります。将来的には、これらの新しい機能を活用して、FlatListやTextInputなどの組み込みコンポーネントにさらなる改善をもたらす予定です。

Reanimatedのような人気ライブラリは、すでに新しいレンダラーを活用しています。

「現在開発中のReanimated 4は、新しいレンダラーと直接連携する新しいアニメーションエンジンを導入し、異なるスレッド間でアニメーションを処理し、レイアウトを管理できるようになります。新しいレンダラーの設計こそが、多くの回避策に頼ることなくこれらの機能の構築を真に可能にするものです。さらに、C++で実装されプラットフォーム間で共有されているため、Reanimatedの大部分は一度書くだけで済み、プラットフォーム固有の問題を減らし、コードベースを最小化し、アウトオブツリープラットフォームへの導入を効率化できます。」

Krzysztof Magiera, Reanimatedの作者

イベントループ

新アーキテクチャにより、このRFCで説明されているように、明確に定義されたイベントループ処理モデルを実装することができました。このRFCはHTML Standardで説明されている仕様に従っており、React NativeがJavaScriptスレッドでタスクをどのように実行すべきかを記述しています。

明確に定義されたイベントループを実装することで、React DOMとReact Nativeの間のギャップが埋まります。React Nativeアプリケーションの振る舞いは、React DOMアプリケーションの振る舞いに近づき、「一度学べば、どこでも書ける」がより容易になります。

イベントループはReact Nativeに多くの利点をもたらします。

イベントやタスクを処理するためにレンダリングを中断する能力
Web仕様とのより緊密な連携
さらなるブラウザ機能のための基盤

イベントループにより、Reactは更新とイベントを予測可能な順序で処理できるようになります。これにより、Reactは優先度の低い更新を緊急のユーザーイベントで中断でき、新しいレンダラーによってそれらの更新を独立してレンダリングできます。

イベントループはまた、タイマーのようなイベントやタスクの振る舞いをWeb仕様と整合させます。これは、React NativeがWebでユーザーが慣れ親しんでいるものと同様に動作し、React DOMとReact Nativeの間でのコード共有を改善することを意味します。

また、マイクロタスク、MutationObserver、IntersectionObserverのような、より準拠したブラウザ機能の実装を可能にします。これらの機能はまだReact Nativeで使用できる準備ができていませんが、将来的には提供できるよう作業を進めています。

最後に、イベントループと新しいレンダラーによるレイアウトの同期的読み取りサポートの変更により、React NativeはuseLayoutEffectの適切なサポートを追加し、レイアウト情報を同期的に読み取り、同じフレーム内でUIを更新できるようになりました。これにより、ユーザーに表示される前に要素を正しく配置できます。

詳細はuseLayoutEffectをご覧ください。

ブリッジの削除

新アーキテクチャでは、React Nativeのブリッジへの依存を完全に排除し、JSIを使用したJavaScriptとネイティブコード間の直接的で効率的な通信に置き換えました。

ブリッジを削除することで、ブリッジの初期化を回避し、起動時間が改善されます。例えば、旧アーキテクチャでは、JavaScriptにグローバルメソッドを提供するために、起動時にJavaScriptでモジュールを初期化する必要があり、アプリの起動時間にわずかな遅延を引き起こしていました。

// ❌ Slow initialization
import {NativeTimingModule} from 'NativeTimingModule';
global.setTimeout = timer => {
  NativeTimingModule.setTimeout(timer);
};

// App.js
setTimeout(() => {}, 100);

新アーキテクチャでは、C++から直接メソッドをバインドできます。

// ✅ Initialize directly in C++
runtime.global().setProperty(runtime, "setTimeout", createTimer);

// App.js
setTimeout(() => {}, 100);

この書き直しにより、特に起動時のJavaScriptクラッシュにおけるエラー報告が改善され、未定義の動作によるクラッシュが減少します。クラッシュが発生した場合、新しいReact Native DevToolsがデバッグを簡素化し、新アーキテクチャをサポートします。

ブリッジは、新アーキテクチャへの段階的な移行をサポートするための後方互換性のために残されています。将来的には、ブリッジのコードを完全に削除する予定です。

段階的な移行

ほとんどのアプリは、他のリリースと同じ労力で0.76にアップグレードできると期待しています。

0.76にアップグレードすると、新アーキテクチャとReact 18がデフォルトで有効になります。ただし、並行（concurrent）機能を使用し、新アーキテクチャの利点を最大限に享受するためには、アプリとライブラリを新アーキテクチャを完全にサポートするように段階的に移行する必要があります。

最初にアップグレードしたとき、アプリは旧アーキテクチャとの自動相互運用性（interop）レイヤーを備えた新アーキテクチャ上で実行されます。ほとんどのアプリでは、これは変更なしで動作しますが、interopレイヤーには既知の制限があります。カスタムShadow Nodeへのアクセスや並行機能をサポートしていません。

並行機能を使用するには、アプリもConcurrent Reactをサポートするように更新する必要があります。これにはReactのルールに従う必要があります。JavaScriptコードをReact 18とそのセマンティクスに移行するには、React 18アップグレードガイドに従ってください。

全体的な戦略は、既存のコードを壊さずにアプリケーションを新アーキテクチャ上で実行させることです。その後、自分のペースでアプリを段階的に移行できます。すべてのモジュールを新アーキテクチャに移行した新しい画面では、すぐに並行機能を使用し始めることができます。既存の画面では、並行機能を追加する前に、いくつかの問題に対処し、モジュールを移行する必要があるかもしれません。

私たちは最も人気のあるReact Nativeライブラリと協力し、新アーキテクチャのサポートを確保しました。すでに850以上のライブラリが互換性を持っており、これには週20万回以上ダウンロードされるすべてのライブラリ（ダウンロードされたライブラリの約10%）が含まれます。ライブラリの新アーキテクチャとの互換性は、reactnative.directoryウェブサイトで確認できます。

アップグレードの詳細については、以下のアップグレード方法を参照してください。

新機能

新アーキテクチャには、React 18、並行機能、そしてReact NativeでのuseLayoutEffectの完全なサポートが含まれています。React 18の機能の全リストについては、React 18のブログ記事をご覧ください。

Transitions

Transitions（トランジション）は、緊急の更新と緊急でない更新を区別するためのReact 18の新しい概念です。

緊急の更新は、タイピングや押下など、直接的なインタラクションを反映します。
トランジション更新は、UIをあるビューから別のビューへ移行させます。

緊急の更新は、物理的なオブジェクトがどのように振る舞うかという私たちの直感に合わせるために、即時の応答が必要です。しかし、トランジションは異なります。なぜなら、ユーザーは画面上のすべての中間値を期待していないからです。新アーキテクチャでは、React Nativeは緊急の更新とトランジション更新を別々にレンダリングすることができます。

通常、最高のユーザーエクスペリエンスのためには、1つのユーザー入力が緊急の更新と非緊急の更新の両方をもたらすべきです。ReactDOMと同様に、pressやchangeのようなイベントは緊急として扱われ、即座にレンダリングされます。入力イベント内でstartTransition APIを使用して、どの更新が「トランジション」であり、バックグラウンドに遅延させることができるかをReactに通知できます。

import {startTransition} from 'react';

// Urgent: Show the slider value
setCount(input);

// Mark any state updates inside as transitions
startTransition(() => {
  // Transition: Show the results
  setNumberOfTiles(input);
});

緊急のイベントをトランジションから分離することで、より応答性の高いユーザーインターフェースと、より直感的なユーザーエクスペリエンスが可能になります。

以下は、トランジションがない旧アーキテクチャと、トランジションがある新アーキテクチャの比較です。各タイルが背景色を持つ単純なビューではなく、画像や他のコンポーネントを含むレンダリングにコストがかかるリッチなコンポーネントであると想像してください。useTransitionを使用した後は、アプリを更新でスラッシングさせることなく、遅れをとることもありません。

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:** トランジションとしてマークせずにタイルをレンダリング。

詳細については、Support for Concurrent Renderer and Features を参照してください。

自動バッチ処理

新アーキテクチャにアップグレードすると、React 18の自動バッチ処理の恩恵を受けることができます。

自動バッチ処理により、Reactはレンダリング時に複数回のstate更新をまとめてバッチ処理し、中間状態のレンダリングを回避できます。これにより、開発者からの追加コードなしで、React Nativeがより高速になり、ラグの影響を受けにくくなります。

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:** レガシーレンダラーで頻繁なstate更新をレンダリング。

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:** *自動バッチ処理*で頻繁なstate更新をレンダリング。

旧アーキテクチャでは、より多くの中間状態がレンダリングされ、スライダーの動きが止まってもUIは更新され続けます。新アーキテクチャでは、レンダリングされる中間状態が少なく、更新を自動的にバッチ処理することで、レンダリングがはるかに早く完了します。

詳細については、Support for Concurrent Renderer and Features を参照してください。

useLayoutEffect

イベントループとレイアウトを同期的に読み取る能力を基盤として、新アーキテクチャではReact NativeにuseLayoutEffectの適切なサポートを追加しました。

旧アーキテクチャでは、ビューのレイアウト情報を読み取るために非同期のonLayoutイベントを使用する必要がありました（これも非同期でした）。その結果、レイアウトが読み取られて更新されるまで、少なくとも1フレームはレイアウトが不正確になり、ツールチップが間違った位置に配置されるなどの問題が発生していました。

// ❌ async onLayout after commit
const onLayout = React.useCallback(event => {
  // ❌ async callback to read layout
  ref.current?.measureInWindow((x, y, width, height) => {
    setPosition({x, y, width, height});
  });
}, []);

// ...
<ViewWithTooltip
  onLayout={onLayout}
  ref={ref}
  position={position}
/>;

新アーキテクチャは、useLayoutEffectでレイアウト情報に同期的にアクセスできるようにすることでこれを修正します。

// ✅ sync layout effect during commit
useLayoutEffect(() => {
  // ✅ sync call to read layout
  const rect = ref.current?.getBoundingClientRect();
  setPosition(rect);
}, []);

// ...
<ViewWithTooltip ref={ref} position={position} />;

この変更により、レイアウト情報を同期的に読み取り、同じフレーム内でUIを更新できるため、ユーザーに表示される前に要素を正しく配置できます。

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 — 旧アーキテクチャでは、レイアウトは`onLayout`で非同期に読み取られたため、ツールチップの位置が遅れていました。

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. — 新アーキテクチャでは、レイアウトは`useLayoutEffect`で同期的に読み取ることができ、表示前にツールチップの位置を更新します。

詳細については、Synchronous Layout and Effects のドキュメントを参照してください。

Suspenseの完全サポート

Suspenseを使用すると、コンポーネントツリーの一部がまだ表示準備ができていない場合に、そのローディング状態を宣言的に指定できます。

<Suspense fallback={<Spinner />}>
  <Comments />
</Suspense>

数年前にSuspenseの限定版を導入し、React 18で完全なサポートが追加されました。これまで、React NativeはSuspenseの並行レンダリングをサポートできませんでした。

新アーキテクチャには、React 18で導入されたSuspenseの完全なサポートが含まれています。これは、React NativeでSuspenseを使用してコンポーネントのローディング状態を処理できるようになったことを意味します。サスペンドされたコンテンツは、ローディング状態が表示されている間バックグラウンドでレンダリングされ、表示されているコンテンツ上のユーザー入力に高い優先度が与えられます。

詳細については、RFC for Suspense in React 18 を参照してください。

アップグレード方法

0.76にアップグレードするには、リリース投稿の手順に従ってください。このリリースはReact 18にもアップグレードするため、React 18アップグレードガイドにも従う必要があります。

これらの手順は、旧アーキテクチャとの相互運用性（interop）レイヤーのおかげで、ほとんどのアプリが新アーキテクチャにアップグレードするのに十分なはずです。ただし、新アーキテクチャを最大限に活用し、並行機能の使用を開始するには、カスタムのネイティブモジュールとネイティブコンポーネントを移行して、新しいネイティブモジュールとネイティブコンポーネントAPIをサポートする必要があります。

カスタムのネイティブモジュールを移行しないと、共有C++、同期メソッド呼び出し、またはcodegenによる型安全性の利点を得ることはできません。ネイティブコンポーネントを移行しないと、並行機能を使用することはできません。できるだけ早く、すべてのネイティブコンポーネントとネイティブモジュールを新アーキテクチャに移行することをお勧めします。

注記

将来のリリースでは、相互運用性（interop）レイヤーを削除し、モジュールは新アーキテクチャをサポートする必要があります。

アプリ

アプリ開発者の方は、新アーキテクチャを完全にサポートするために、ライブラリ、カスタムネイティブコンポーネント、およびカスタムネイティブモジュールをアップグレードして、新アーキテクチャを完全にサポートする必要があります。

私たちは最も人気のあるReact Nativeライブラリと協力し、新アーキテクチャのサポートを確保しました。ライブラリの新アーキテクチャとの互換性は、reactnative.directoryウェブサイトで確認できます。

アプリが依存しているライブラリのいずれかがまだ互換性がない場合は、次のことができます。

ライブラリにissueを立て、作者に新アーキテクチャへの移行を依頼する。
ライブラリがメンテナンスされていない場合は、同じ機能を持つ代替ライブラリを検討する。
これらのライブラリが移行される間、新アーキテクチャをオプトアウトする。

アプリにカスタムのネイティブモジュールやカスタムのネイティブコンポーネントがある場合、私たちの相互運用性（interop）レイヤーのおかげで、それらは問題なく動作すると期待しています。ただし、新アーキテクチャを完全にサポートし、並行機能を採用するためには、それらを新しいネイティブモジュールおよびネイティブコンポーネントAPIにアップグレードすることをお勧めします。

モジュールとコンポーネントを新アーキテクチャに移行するには、以下のガイドに従ってください。

ライブラリ

ライブラリのメンテナーの方は、まずライブラリが相互運用性（interop）レイヤーで動作することをテストしてください。動作しない場合は、New Architecture Working Groupにissueを立ててください。

新アーキテクチャを完全にサポートするために、できるだけ早くライブラリを新しいネイティブモジュールおよびネイティブコンポーネントAPIに移行することをお勧めします。これにより、ライブラリのユーザーは新アーキテクチャを最大限に活用し、並行機能をサポートできるようになります。

モジュールとコンポーネントを新アーキテクチャに移行するには、これらのガイドに従うことができます。

オプトアウト

何らかの理由で、新アーキテクチャがアプリケーションで正しく動作しない場合、再度有効にする準備ができるまで、いつでもオプトアウトするオプションがあります。

新アーキテクチャからオプトアウトするには：

Androidでは、android/gradle.propertiesファイルを変更し、newArchEnabledフラグをオフにします。

-newArchEnabled=true
+newArchEnabled=false

iOSでは、次のコマンドを実行して依存関係を再インストールできます。

RCT_NEW_ARCH_ENABLED=0 bundle exec pod install

謝辞

OSSコミュニティに新アーキテクチャを提供することは、数年にわたる研究開発を要した大きな努力でした。この結果を達成するのに協力してくれた、現在および過去のReactチームのすべてのメンバーに感謝の意を表したいと思います。

また、これを実現するために協力してくださったすべてのパートナーに心から感謝しています。特に、以下の皆様に感謝を申し上げます。

Expo、早期に新アーキテクチャを採用し、最も人気のあるライブラリの移行作業をサポートしてくださったこと。
Software Mansion、エコシステムにおける重要なライブラリを維持し、早期に新アーキテクチャに移行し、様々な問題の調査と修正に多大な協力をしてくださったこと。
Callstack、エコシステムにおける重要なライブラリを維持し、早期に新アーキテクチャに移行し、Community CLIの作業をサポートしてくださったこと。
Microsoft、react-native-windowsおよびreact-native-macos、ならびに他のいくつかの開発者ツールに新アーキテクチャの実装を追加してくださったこと。
Expensify, Kraken, Bluesky, Brigad、新アーキテクチャの採用を先駆けて行い、様々な問題を報告してくださったことで、私たちは他のすべての人のためにそれらを修正できました。
新アーキテクチャをテストし、いくつかの問題を修正し、不明確な点について質問を提起してくださることで、私たちがそれらを明確にすることができた、すべての独立したライブラリメンテナーと開発者の皆様。

新アーキテクチャとは​

新しいネイティブモジュール​

新しいレンダラー​

イベントループ​

ブリッジの削除​

段階的な移行​

新機能​

Transitions​

自動バッチ処理​

useLayoutEffect​

Suspenseの完全サポート​

アップグレード方法​

アプリ​

ライブラリ​

オプトアウト​

謝辞​