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

React Nativeコアコントリビューターサミット2024レポート

·10分で読めます
Michał Pierzchała
Michał Pierzchała
テクノロジー責任者 @ Callstack
Szymon Rybczak
Szymon Rybczak
ソフトウェアエンジニア @ Callstack
Mo Javad
Mo Javad
モバイル責任者（英国） @ Theodo
Steven Moyes
Steven Moyes
シニアプロダクトマネージャー @ Microsoft

毎年、React NativeコミュニティのコアコントリビューターがReact Nativeチームと共に集まり、このプロジェクトの方向性を共同で決定します。

昨年も例外ではありませんでした。通常、私たちはReact Universe Conf（旧React Native EU）の前日に、ヴロツワフにあるCallstack本社でミーティングを行っていました。2024年には、過去の経験から学び、より自由に過ごせる時間を確保するため、2日連続でサミットを開催しました。

all-participants

この毎年恒例の伝統は、コントリビューターが洞察を共有し、懸念を表明し、コアチームが計画を共有し、パートナー企業、個人のライブラリ作成者、友人を含むReact Nativeエコシステムの主要なコントリビューターからフィードバックを収集する貴重な機会となっています。

サミットは以下のトピックをカバーする2つのトラックに分かれました。

このブログ記事では、この集まりの結果を少しだけご紹介したいと思います。

リリース​

React Nativeのリリースプロセスについて広範な議論を行いました。コアチームは、Meta以外のコントリビューターがリリースに関わることの価値を評価し、特にReact Native visionOSのようなツリー外プラットフォーム、ライブラリメンテナー（Reanimated）、フレームワーク（Expo）にとって有益なナイトリーリリースの重要性を強調しています。リリース頻度については、修正をより早く提供するために、より頻繁なリリースを求める声もありましたが、他の人々は、サードパーティライブラリへの影響やアップグレード作業への懸念を表明しました。

また、意図しない破壊的変更を減らし、React Nativeとサードパーティ依存関係との互換性に関するコミュニケーションを改善する方法についても議論しました。

このセッションでは、React Nativeのリリースを管理することがいかに複雑であるか、また、考慮すべきエコシステムのさまざまな部分を考慮すると、このトピックがいかにデリケートであるかが示されました。

新しいアーキテクチャの次のステップは？​

新しいアーキテクチャが安定版として出荷された今、次に何に焦点を当てるべきかについて議論しました。次に来る大きなものは何でしょうか？議論は次のトピックを中心に展開されました。

  • Web互換性 – React Strict DOMプロジェクトの方向性に関する議論で結論が出ました。これは一時的なポリフィルとして扱われるべきであり、XplatチームはReact Nativeのコアに適切なクロスプラットフォーム機能を実装します。
  • コアAPIの安定化 – これがアプリ開発者、ライブラリ作成者、ツリー外プラットフォームにとって何を意味するのかについて、より多くの合意が必要であることが判明しました。例えば、共有C++コードベースからiOSおよびAndroid用のプラットフォーム固有ロジックを抽出する必要があるかもしれません。これの一部はLeanCore 2.0の議論でカバーされました。
  • 古いアーキテクチャのサポート – 予想通り、チームは並行レンダリングに基づく新しいReact 19の機能が古いアーキテクチャでは動作しないことを確認しました。新しい機能は主に新しいアーキテクチャを対象としています。React 19のリリーススケジュールにおけるブロッカーのため、新しいアーキテクチャと古いアーキテクチャの両方でサポートされる機能の境界線をどこに引くべきかはまだ不明確です。
  • React Native用サードパーティライブラリ – 今日、ライブラリ作成者はTurboModules、ExpoModules、最近ではNitroModulesを使用して、ネイティブプラットフォーム機能のブリッジングという同じ目標を達成できます。その方法に関するより良いドキュメントが必要です。
  • ブラウンフィールドドキュメント – サミット開催当時、React Nativeをネイティブアプリに統合するための公式ドキュメントはかなり古くなっていました。それ以来、チームはAndroidとiOS向けに最新でよりシンプルなドキュメントを公開しています。
  • Metro webのツリーシェイキング – コアMetroチームは、この分野におけるExpoチームの作業のマージに前向きです。

Native ModulesのためのWeb API​

このセッションは、Web APIのサブセットをReact Nativeに導入するというMicrosoftのRFCに捧げられました。これは、なじみのあるAPIを活用することで、React Nativeのスケーラビリティを向上させ、より多くのWeb開発者を引きつけることを目指しています。明示的なReact Nativeサポートを持たない既存のオープンソースWebライブラリの豊富な資産へのアクセスを開放します。

web-apis

Web API仕様の標準化は、React Nativeの成長にとって有益であるだけでなく不可欠であり、当社の多プラットフォームビジョンとreact-strict-domプロジェクトとよく一致しています。Webは仕様を通じて統一されたインターフェースを提供しますが、React Nativeコミュニティモジュールは現在これを欠いています。Microsoftは、iOS、Android、Windows、macOSといったサポートするプラットフォーム向けに最初に実装できる約200の重要なWeb APIを特定しました。

この標準化により、プラットフォーム間でのコードの移植性と開発者エクスペリエンスが向上するため、ライブラリ開発者は可能な限りWeb仕様にAPIを合わせることをお勧めします。

この提案はReact Nativeの将来にとって有益に見えますが、私たちは次のステップをまだ検討しています。私たちが気づいた懸念の1つはAPIのガバナンスであり、それらがプラットフォーム実装とは別のリポジトリに存在する必要があるかどうかです。もう1つは、特定のプラットフォームがW3Cで指定されていない動作を許可する場合に、公式仕様から逸脱することです。不要なモジュールのバンドルを回避する方法（例：Babelプラグインを使用）を見つける必要があります。このようなイニシアチブの範囲が非常に広いことは言うまでもありません。

セッションの結論は2つの重要な点を強調しました。第一に、可能であればWeb互換仕様を採用するという点で、React Nativeコミュニティ全体で強い連携があります。第二に、これらのWeb API実装を異なるプラットフォームで個別に維持する方法について、明確な技術戦略を確立する必要があります。MicrosoftはCallstackと協力して、元のRFCを洗練させ、コミュニティイニシアチブとして少数のAPIの概念実証実装を作成する可能性があります。この漸進的なアプローチは、範囲を拡大する前に設計と開発者エクスペリエンスを検証するのに役立ちます。

LeanCore 2.0​

2019年、React NativeチームはLean Coreイニシアチブを開始しました。目標は、React Nativeのコアの表面積に取り組み、古くてレガシーなAPIとコンポーネントを削減することでした。それ以来、React NativeのコンポーネントとAPIの表面は、もう一度クリーンアップが必要でした。

今日では、より優れたコミュニティ代替品がありながら、積極的にメンテナンスされていないコンポーネントが多数存在します。さらに、メンテナンスのために最終的に統合されるべき重複したコンポーネントもあります。

API側では、多くのJSレイヤーAPIが、真にプラットフォームに依存しないのではなく、ネイティブのiOSおよびAndroidの実装に結び付けられています。たとえば、Pressableにはandroid_disableSoundやandroid_rippleのようなpropsがあります。理想的には、React Nativeコンポーネントは、特定のプラットフォームに縛られない最小限のAPIサーフェスを持つべきです。

ツリー外プラットフォームが成長し、エコシステムでより広く採用されるにつれて、React NativeコアのコンポーネントとAPIサーフェスを削減する道筋が必要であり、これによりReact Nativeコアチームの負担が軽減され、ツリー外プラットフォームおよびライブラリのメンテナーが最新の状態を維持することが著しく容易になります。

さらに、これにより、初心者アプリ開発者がReact Nativeを習得しやすくなります。重複したコンポーネントや「落とし穴」が少なくなるためです。より良いコミュニティの代替品がある場合、開発者はその利用を促され、奨励されます。

セッション中、私たちは以下について議論しました。

  • Lean Coreのハイレベルな動機と、関係者（開発者、ライブラリメンテナー、Meta）へのメリット
  • 実際のプロダクションReact Nativeアプリで使用されているコンポーネントの集約ビュー
  • コアから削除される候補となるコンポーネントの基準
  • 以下の内容を含むLean Core 2.0を実行するための明確な行動計画
    • 非推奨化のハイレベルなプロセス
    • Metaが社内で、より優れたコミュニティ代替品を持つコンポーネントを使用している場合の処理

次のステップとして、コアコントリビューターのグループが、より多くのテレメトリとデータを収集し、コミュニティ代替品を評価し、提案された変更を詳述するRFCをまとめる予定です。

Nitro Modules - propsをjsi::Valuesとして公開することでビューコンポーネントのブロックを解除する​

最近、Marc RousavyはNative Modulesを作成するための代替アプローチとしてNitro Modulesを発表しました。Nitro Modulesは実験的なC++ Swift Interopを利用し、特定のシナリオでパフォーマンス向上につながる多くの機能強化を組み込んでいます。しかし、このセッションでは、Nitro Modulesと既存のTurboModules間のさまざまなトレードオフについて議論しました。

Nitro Modulesはいくつかのパフォーマンス上の利点を提供しますが、対処する必要がある制限と考慮事項も存在します。たとえば、実験的なインターオップ機能の使用は、TurboModulesには存在しない複雑さや互換性の問題を引き起こす可能性があります。私たちの議論は、これらのトレードオフと、Nitro Modulesの改善の一部をReact Native Coreにアップストリームする可能性に焦点を当てました。これにより、開発者はより高性能なモジュールの恩恵を誰もが受けられるようになります。

ツリー外プラットフォームとCocoaPods​

ツリー外プラットフォームはReact Nativeの真の力を示します。そこでは、モバイルデバイス、デスクトップ、さらにはVR/XRデバイス上で動作するさまざまなプラットフォーム間で1つのJSコードベースを共有できます。現在、そのようなプラットフォームを作成することは最も簡単なプロセスではなく、実際には、どのように作成、開発、保守すべきかについてのガイドラインはありません。また、React Native Coreはある意味でAndroidおよびiOSプラットフォームに結びついています。将来的には、すべてのプラットフォームが平等に扱われ、同じAPIを介してC++/JSコアと統合するシナリオを目指すことができます。

oot-platforms

このセッションでは、異なるプラットフォームのメンテナーが、問題点、苦労している点、新しいツリー外プラットフォームの作成と保守のプロセスを統一するための解決策について議論しました。

このセッションのもう1つの側面は、CocoaPodsとネイティブ依存関係の管理に関連する将来の計画について議論することでした。最近、CocoaPodsチームはメンテナンスモードに移行し、新しい主要な改善や機能は出荷されないことを発表しました。使用できるさまざまな代替案があり、このセッションではそれらの長所と短所、および移行がどのようなものになるかについて議論しました。

デスクトップ上のReact Native​

MicrosoftのStevenとSaad（react-native-windowsおよびreact-native-macosのメンテナー）は、デスクトッププラットフォームに関連するコントリビューターからのフィードバックを聞き、収集するためのセッションを主催しました。議論されたトピックには、デスクトップ向けReact Nativeの採用を増やす方法（Visual Studioに専用のワークフローを持たせる、またはNxの一部としてデスクトップを公開するなど）や、Expoのサポート方法が含まれました。Expoは、採用をさらに進める上で常に課題となっています。

macOSとWindowsの間には、コミュニティモジュールの利用可能性において大きな格差があります。これは主に、iOSコードがほとんどmacOSと互換性があるのに対し、RNWには特注の実装が必要であるという事実によるものです。React Native for Windowsの新しいアーキテクチャに取り組む中で、チームはC++モジュールがプラットフォーム間でさらに多くのコード共有を可能にし、デスクトッププラットフォームをターゲットにする負担を軽減する可能性を見ています。コミュニティ側では、Software MansionがReact Native Screens、Gesture Handler、Reanimatedなど、最も人気のあるモジュールにデスクトップサポートを追加する作業を行っていることに注目する価値があります。

数日間一緒に数時間を過ごすことで、これほど多くの知識共有とアイデアの相互交流が生まれたことに、私たちは今も感銘を受けています。このサミットでは、React Nativeエコシステムを改善し、再構築するのに役立つイニシアチブの種を蒔きました。

React Nativeの開発に参加することに興味がある場合は、当社のオープンイニシアチブに参加し、当社のウェブサイトにある貢献ガイドを必ず読んでください。将来、直接お会いできることを願っています！