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

サンフランシスコミートアップのレポート

·9分で読めます
Héctor Ramos
Héctor Ramos
元Facebook デベロッパーアドボケイト

先週、私はZyngaのサンフランシスコオフィスで開催されたReact Native Meetupに参加する機会を得ました。約200人が参加し、近くでReact Nativeに興味を持っている他の開発者と出会うのに最適な場所となりました。

私は特に、Zynga、Netflix、Airbnbといった企業でReactとReact Nativeがどのように使われているかについて学ぶことに興味がありました。その夜のアジェンダは以下の通りでした。

  • Reactにおけるラピッドプロトタイピング
  • React NativeのためのAPI設計
  • ギャップを埋める：既存のコードベースでReact Nativeを使用する

しかし、まずイベントは簡単な紹介と最近のニュースの簡単な要約から始まりました。

お近くでこれらのミートアップが開催される場合は、ぜひ参加することをお勧めします！

ZyngaでのReactによる高速プロトタイピング​

最初のニュースラウンドに続いて、この夜のホストであるZyngaによる簡単な紹介がありました。Abhishek Chadha氏は、モバイルで新しい体験を迅速にプロトタイプするためにReactをどのように使用しているかについて話し、Draw Somethingのようなアプリの簡単なプロトタイプをデモしました。彼らはReact Nativeと同様のアプローチを使用し、ブリッジを介してネイティブAPIへのアクセスを提供しています。これは、Abhishekがデバイスのカメラを使って観客の写真を撮り、その後誰かの頭に帽子を描いたときに実証されました。

NetflixでのReact Native向けAPI設計​

次に、この夜の最初の特集講演です。NetflixのシニアソフトウェアエンジニアであるClarence Leung氏が、React Native向けAPI設計に関する講演を行いました。まず彼は、開発者が扱う可能性のある2つの主要なライブラリの種類について言及しました。それは、タブバーや日付ピッカーなどのコンポーネントと、カメラロールやアプリ内課金などのネイティブサービスへのアクセスを提供するライブラリです。React Nativeで使うライブラリを構築する際には、2つのアプローチがあります。

  • プラットフォーム固有のコンポーネントを提供する
  • AndroidとiOSの両方で同様のAPIを持つクロスプラットフォームライブラリ

それぞれのアプローチには独自の考慮事項があり、自分のニーズに最も適したものを決定するのはあなた次第です。

アプローチ #1

プラットフォーム固有のコンポーネントの例として、ClarenceはReact NativeコアのDatePickerIOSとDatePickerAndroidについて話しました。iOSでは、日付ピッカーはUIの一部としてレンダリングされ、既存のビューに簡単に埋め込むことができますが、Androidでは日付ピッカーはモーダルで表示されます。この場合は個別のコンポーネントを提供することが理にかなっています。

アプローチ #2

一方、写真ピッカーはAndroidとiOSで同様に扱われます。AndroidがiOSのように写真をセルフィーなどのフォルダにグループ化しないなど、若干の違いはありますが、それらは`if`文と`Platform`コンポーネントを使って簡単に処理できます。

どちらのアプローチを採用するにしても、APIサーフェスを最小限に抑え、アプリ固有のライブラリを構築することをお勧めします。たとえば、iOSのApp内課金フレームワークは、1回限りの消費型購入と、自動更新型サブスクリプションの両方をサポートしています。アプリが消費型購入のみをサポートする必要がある場合、クロスプラットフォームライブラリでサブスクリプションのサポートを削除しても問題ないかもしれません。

Clarence氏のトークの最後には、短いQ&Aセッションがありました。そこから出てきた興味深い情報の一つは、Netflixでこれらのライブラリのために書かれたReact Nativeコードの約80%が、AndroidとiOSの両方で共有されているということでした。

ギャップを埋める、既存のコードベースでのReact Nativeの使用​

この夜最後の講演は、AirbnbのLeland Richardson氏によるものでした。講演は、既存のコードベースでReact Nativeを使用することに焦点を当てていました。私はReact Nativeを使って新しいアプリをゼロから書くのがどれほど簡単か知っていたので、Airbnbが既存のネイティブアプリにReact Nativeを導入した経験について聞くことに非常に興味がありました。

リーランド氏は、グリーンフィールドアプリとブラウンフィールドアプリについて語り始めました。グリーンフィールドとは、以前の作業を考慮する必要なくプロジェクトを開始することを意味します。これは、既存のプロジェクトの要件、開発プロセス、およびチームのさまざまなニーズを考慮する必要があるブラウンフィールドプロジェクトとは対照的です。

グリーンフィールドアプリで作業している場合、React Native CLIはAndroidとiOSの両方に単一のリポジトリを設定し、すべてが機能します。AirbnbでReact Nativeを使用する際の最初の課題は、AndroidとiOSアプリがそれぞれ独自のリポジトリを持っていたという事実でした。複数のリポジトリを持つ企業は、React Nativeを採用する前にいくつかのハードルを乗り越える必要があります。

これを回避するため、AirbnbはまずReact Nativeのコードベース用に新しいリポジトリを設定しました。彼らは継続的インテグレーションサーバーを使用して、AndroidとiOSのリポジトリをこの新しいリポジトリにミラーリングしました。テストが実行され、バンドルがビルドされた後、ビルドアーティファクトはAndroidとiOSのリポジトリに同期されます。これにより、モバイルエンジニアは開発環境を変更することなくネイティブコードで作業できます。モバイルエンジニアは、npmをインストールしたり、パッカーを実行したり、JavaScriptバンドルをビルドすることを覚えておく必要はありません。実際のReact Nativeコードを書くエンジニアは、React Nativeリポジトリで直接作業するため、コードをAndroidとiOS間で同期することを心配する必要はありません。

これにはいくつかの欠点があります。主に、アトミックな更新を配信できないことでした。ネイティブコードとJavaScriptコードの組み合わせが必要な変更には、3つの個別のプルリクエストが必要であり、これらはすべて慎重にマージする必要がありました。競合を避けるために、ビルドが開始されてからマスターが変更されている場合、CIは変更をAndroidおよびiOSリポジトリに戻すことを拒否します。これにより、コミット頻度が高い日（新しいリリースがカットされる日など）には長い遅延が発生する可能性がありました。

Airbnbはその後、モノレポアプローチに移行しました。幸いなことに、これはすでに検討されており、AndroidとiOSのチームがReact Nativeの使用に慣れると、彼らは喜んでモノレポへの移行を加速させました。

これにより、分割リポジトリのアプローチで抱えていた問題のほとんどが解決されました。Leland氏は、これがバージョン管理サーバーにより高い負荷をかけることになり、小規模な企業にとっては問題になる可能性があると指摘しました。

ナビゲーション問題​

Leland氏の講演の後半は、私にとって重要なテーマであるReact Nativeにおけるナビゲーション問題に焦点を当てていました。彼は、React Nativeにおける数多くのナビゲーションライブラリ、すなわちファーストパーティとサードパーティの両方について語りました。NavigationExperimentalは有望に見えたが、彼らのユースケースには適していなかったと述べました。

実際、既存のナビゲーションライブラリのどれもブラウンフィールドアプリではうまく機能しないようです。ブラウンフィールドアプリでは、ナビゲーションの状態が完全にネイティブアプリによって所有される必要があります。たとえば、React Nativeビューが表示されている間にユーザーのセッションが期限切れになった場合、ネイティブアプリは必要に応じて引き継ぎ、ログイン画面を表示できる必要があります。

Airbnbはまた、移行の一環としてネイティブのナビゲーションバーをJavaScriptバージョンに置き換えることを避けたいと考えていました。その効果がぎこちなくなる可能性があるためです。当初はモーダル表示されるビューに限定していましたが、これはアプリ内でReact Nativeをより広く採用する際に明らかな問題となりました。

彼らは独自のライブラリが必要だと判断しました。そのライブラリは`airbnb-navigation`と呼ばれています。このライブラリはAirbnbのコードベースと強く結びついているため、まだオープンソース化されていませんが、年末までにリリースしたいと考えています。

ライブラリのAPIについて詳しくは触れませんが、以下にいくつかの重要なポイントを挙げます。

  • シーンを事前に登録する必要がある
  • 各シーンは独自のRCTRootView内に表示されます。これらは各プラットフォームでネイティブに表示されます（例：iOSではUINavigationControllerが使用されます）。
  • シーン内のメインのScrollViewはScrollSceneコンポーネントでラップする必要があります。そうすることで、iOSでステータスバーをタップして一番上にスクロールするなどのネイティブの動作を活用できます。
  • シーン間のトランジションはネイティブで処理されるため、パフォーマンスについて心配する必要はありません。
  • Androidのバックボタンは自動的にサポートされます。
  • Navigator.ConfigというUIレスコンポーネントを介して、View Controllerベースのナビゲーションバーのスタイリングを活用できます。

また、留意すべきいくつかの考慮事項もあります。

  • ナビゲーションバーはネイティブコンポーネントであるため、JavaScriptで簡単にカスタマイズすることはできません。これは意図的なもので、ネイティブのナビゲーションバーを使用することがこのタイプのライブラリの厳しい要件だからです。
  • ScreenPropsはブリッジを介して送信されるたびにシリアライズ/デシリアライズする必要があるため、ここで大量のデータを送信する際には注意が必要です。
  • ナビゲーションの状態はネイティブアプリによって所有されているため（これもライブラリの厳しい要件）、Reduxのようなものでナビゲーションの状態を操作することはできません。

Leland氏の講演の後には質疑応答セッションも行われました。全体として、AirbnbはReact Nativeに満足しています。彼らはApp Storeを通さずに問題を修正するためにCode Pushを使用することに興味があり、エンジニアはLive Reloadを気に入っています。マイナーな変更のたびにネイティブアプリを再構築するのを待つ必要がないからです。

閉会の辞​

イベントは、いくつかの追加のReact Nativeニュースで締めくくられました。

ミートアップは、コミュニティ内の他の開発者と出会い、学ぶ良い機会を提供します。今後もReact Nativeのミートアップに積極的に参加していきたいと思います。もしこれらのミートアップに参加される機会があれば、ぜひ私を見つけて、React Nativeをより良く活用するためにどうすればよいか教えてください！