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

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チームと共に集まり、このプロジェクトの方向性を共同で決定します。

昨年も例外ではありませんでした — 少しの違いはありましたが。私たちは通常、Callstack のヴロツワフ本社で React Universe Conf (旧 React Native EU) の前日に会合を開きます。2024年は、過去の経験から学び、サミットを2日間連続で開催し、より自由な時間を一緒に過ごせるようにしました。

all-participants

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

私たちはサミットを2つのトラックに分け、以下のトピックを取り上げました。

このブログ記事では、この集まりの成果を少しだけお見せしたいと思います。

リリース​

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

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

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

新アーキテクチャの次は？​

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

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

ネイティブモジュール向けWeb API​

このセッションは、Web APIのサブセットをReact Nativeに導入するというアイデアを中心としたMicrosoftのRFCに特化していました。これは、使い慣れたAPIを活用することでReact Nativeのスケーラビリティを向上させ、より多くのWeb開発者を惹きつけることを目的としています。これにより、明示的なReact Nativeサポートを持たない既存の豊富なオープンソースWebライブラリへのアクセスが可能になります。

web-apis

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

ライブラリ開発者には、可能な限りAPIをWeb仕様に合わせることを奨励します。この標準化は、プラットフォーム間のコードの移植性と開発者体験を向上させるでしょう。

この提案はReact Nativeの将来にとって有益に見えますが、次のステップについてはまだブレインストーミング中です。懸念事項の一つはAPIのガバナンスであり、プラットフォーム実装とは別のリポジトリで管理する必要があるかどうかです。もう一つは、特定のプラットフォームがW3Cによって指定されていない動作を許可する場合に、公式仕様から逸脱することに関する懸念です。Babelプラグインなどを使って、不要なモジュールをバンドルしないようにする方法を見つけ出す必要があります。言うまでもなく、このようなイニシアチブの範囲は非常に大きいです。

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

LeanCore 2.0​

2019年、React NativeチームはLean Coreイニシアチブを開始しました。その目標は、React NativeコアのAPIサーフェスに取り組み、古くなったレガシーなAPIやコンポーネントを削減することでした。それ以来、React NativeのコンポーネントとAPIサーフェスは、再びクリーンアップされるべき時期がとうに過ぎていました。

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

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

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

さらにボーナスとして、これにより初心者のアプリ開発者がReact Nativeを習得しやすくなります。なぜなら、学ぶべき重複したコンポーネントや「落とし穴」が少なくなるからです。より良いコミュニティの代替品がある場合、開発者は利用可能なコミュニティの代替品を使うよう案内され、奨励されることができます。

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

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

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

Nitroモジュール - propsをjsi::Valuesとして公開することによるViewコンポーネントのアンブロック​

最近、Marc Rousavyがネイティブモジュールを作成するための代替アプローチとしてNitroモジュールを導入しました。Nitroモジュールは実験的なC++/Swift Interopを利用し、特定のシナリオでパフォーマンス向上につながる可能性のある多くの改善を取り入れています。しかし、このセッションでは、Nitroモジュールと既存のTurboモジュールとの間のさまざまなトレードオフについて議論しました。

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

Out-of-TreeプラットフォームとCocoaPods​

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

oot-platforms

このセッション中、さまざまなプラットフォームのメンテナーが、問題点、苦労していること、そして新しいOut-of-Treeプラットフォームの作成と保守のプロセスを統一するための解決策について議論しました。

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

デスクトップでのReact Native​

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

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

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

React Nativeの開発に参加することに興味がある方は、ぜひ私たちのオープンなイニシアチブに参加し、ウェブサイトにあるコントリビューションガイドを読んでください。将来、皆さんと直接お会いできることを楽しみにしています！