メインコンテンツへスキップ

React Nativeチームの原則

・読了時間5分
Eli White
Eli White
Metaソフトウェアエンジニア

FacebookのReact Nativeチームは、React Nativeでの作業の優先順位を決定する際に役立つ原則によって導かれています。これらの原則は、特に私たちのチームを表すものであり、必ずしもReact Nativeコミュニティのすべての関係者を代表するものではありません。私たちは、私たちを駆り立てるもの、意思決定の方法、そして努力の焦点をどこに当てるかをより透明にするために、これらの原則を共有しています。

ネイティブエクスペリエンス​

React Nativeの最優先事項は、人々が各プラットフォームに抱く期待に応えることです。これが、React Nativeがプラットフォームプリミティブにレンダリングする理由です。クロスプラットフォームの一貫性よりも、ネイティブのルックアンドフィールを重視しています。

たとえば、React NativeのTextInputは、iOSではUITextFieldにレンダリングされます。これにより、パスワードマネージャーやキーボードコントロールとの統合がすぐに機能します。プラットフォームプリミティブを使用することで、React Nativeアプリは、AndroidとiOSの新しいリリースからのデザインや動作の変更にも対応できます。

ネイティブアプリのルックアンドフィールに合わせるためには、パフォーマンスも合わせなければなりません。これが、私たちが最も野心的な取り組みを集中させる場所です。たとえば、Facebookは、AndroidのReact Native向けにゼロから構築された新しいJavaScriptエンジンであるHermesを作成しました。Hermesは、React Nativeアプリの起動時間を大幅に改善します。また、スレッドモデルを最適化し、React Nativeとネイティブコードの相互運用性を容易にする主要なアーキテクチャ変更にも取り組んでいます。

大規模な規模​

Facebookアプリの何百もの画面がReact Nativeで実装されています。Facebookアプリは、膨大な数のデバイスを使用する数十億人によって使用されています。これが、私たちが大規模な最も困難な問題に投資する理由です。

私たちのアプリでReact Nativeを展開することで、小規模では見られない問題を特定できます。たとえば、Facebookは、最新のiPhoneから多くの古い世代のAndroidデバイスまで、幅広いデバイスにわたるパフォーマンスの向上に重点を置いています。この焦点は、Hermes、Fabric、TurboModulesなどのアーキテクチャプロジェクトに影響を与えています。

React Nativeが大規模な組織にも対応できることを証明しました。何百人もの開発者が同じアプリに取り組んでいる場合、段階的な導入は必須です。これが、React Nativeを一度に1つの画面ずつ導入できるようにした理由です。まもなく、これをさらに一歩進めて、既存のネイティブ画面の個々のネイティブビューをReact Nativeに移行できるようにします。

大規模な規模に焦点を当てているということは、私たちのチームが現在取り組んでいないことがたくさんあることを意味します。たとえば、私たちのチームは、業界におけるReact Nativeの導入を推進していません。また、大規模では見られない問題に対する解決策を積極的に構築もしていません。私たちは、多くのパートナーとコアコントリビューターがコミュニティにとって重要な分野に焦点を当てることができることを誇りに思っています。

開発速度​

優れたユーザーエクスペリエンスは、繰り返し作成されます。実行中のアプリでコード変更の結果を確認するのに数秒しかかかりません。React Nativeのアーキテクチャにより、開発中にほぼ瞬時のフィードバックを提供できます。

React Nativeの採用により開発速度が大幅に向上したというチームの話はよく聞きます。これらのチームは、開発中の瞬時のフィードバックにより、さまざまなアイデアを試したり、小さな変更ごとにコーディングセッションを中断する必要がないため、追加の磨きをかけることがはるかに容易になると考えています。React Nativeに変更を加える際には、この開発エクスペリエンスの品質を維持するように注意しています。

瞬時のフィードバックは、React Nativeが開発速度を向上させる唯一の方法ではありません。チームは、高品質のオープンソースパッケージの急速に成長しているエコシステムを活用できます。チームは、Android、iOS、Web間でビジネスロジックを共有することもできます。これにより、更新をより迅速に配信し、プラットフォームチーム間の組織的なサイロを削減できます。

すべてのプラットフォーム​

2014年にReact Nativeを発表したとき、私たちは「一度学習すれば、どこでも記述できる」というモットーで発表しました—そして、私たちはどこでもを意味しています。開発者は、デバイスモデルやオペレーティングシステムによって制限されることなく、できるだけ多くの人々にリーチできる必要があります。

React Nativeは、モバイル、デスクトップ、Web、TV、VR、ゲーム機など、非常に異なるプラットフォームをターゲットにしています。開発者に最低限の共通分母に対応させるのではなく、各プラットフォームで豊富なエクスペリエンスを実現したいと考えています。これを実現するために、各プラットフォームの独自の機能をサポートすることに重点を置いています。これは、（タッチ、ペン、マウスなど）さまざまな入力メカニズムから、VRの3D環境のような根本的に異なる消費エクスペリエンスまで多岐にわたります。

この原則は、プラットフォーム間のパリティを促進するために、React Nativeの新しいコアアーキテクチャをクロスプラットフォームのC++で実装するという私たちの決定を促しました。また、WindowsやmacOSなどの他のプラットフォームの管理者（Microsoftなど）を対象とした公開インターフェースを改良しています。私たちは、あらゆるプラットフォームでReact Nativeをサポートできるように努めています。

宣言型UI​

私たちは、すべてのプラットフォームでまったく同じユーザーインターフェースを展開することには賛成しません。同じ宣言型プログラミングモデルを使用して、各プラットフォームの独自の機能を公開することに賛成しています。私たちの宣言型プログラミングモデルはReactです。

私たちの経験では、Reactによって普及した一方向データフローにより、アプリケーションの理解が容易になります。命令的に管理されたビューではなく、宣言型コンポーネントの構成として画面を表す方が好みです。WebにおけるReactの成功と新しいネイティブAndroidおよびiOSフレームワークの方向性は、業界も宣言型UIを採用していることを示しています。

Reactは宣言型ユーザーインターフェースを普及させました。しかし、Reactが独自の立場から解決できる未解決の問題はまだたくさんあります。React NativeはReactのイノベーションの上に構築し続け、宣言型ユーザーインターフェースムーブメントの最前線にとどまります。