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

サンフランシスコミートアップ報告

·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を使用する

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

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

ZyngaでのReactでの迅速なプロトタイピング​

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

NetflixでのReact Native用のAPIの設計​

次に、その夜の最初の注目の講演です。Clarence Leung（Netflixのシニアソフトウェアエンジニア）が、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のアプリ内購入フレームワークは、1回限りの消費型購入だけでなく、更新可能なサブスクリプションもサポートしています。アプリが消費型購入のみをサポートする必要がある場合は、クロスプラットフォームライブラリでのサブスクリプションのサポートを削除しても構いません。

Clarenceの講演の最後に、簡単な質疑応答セッションがありました。そこから出てきた興味深い情報の1つは、Netflixでこれらのライブラリ用に書かれたReact Nativeコードの約80％がAndroidとiOSの両方で共有されているということでした。

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

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

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

グリーンフィールドアプリで作業している場合、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つの別々のプルリクエストが必要であり、それらはすべて慎重に投入する必要がありました。競合を回避するために、ビルドの開始以降にmasterが変更された場合、CIはAndroidおよびiOSリポジトリへの変更の投入に失敗します。これにより、コミット頻度が高い日（新しいリリースがカットされるときなど）には長い遅延が発生していました。

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

これにより、彼らが抱えていた分割リポジトリのアプローチに関する問題のほとんどが解決しました。レランドは、これがバージョン管理サーバーへの負荷を高めるため、中小企業にとっては問題になる可能性があると指摘しました。

ナビゲーションの問題​

レランドの講演の後半は、私にとって身近なテーマである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レスのコンポーネントを介して、ビューコントローラーベースのナビゲーションバーのスタイリングを利用できます。

また、留意すべき点がいくつかあります。

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

レランドの講演の後には質疑応答セッションもありました。全体として、AirbnbはReact Nativeに満足しています。彼らはApp Storeを経由せずに問題を修正するためにCode Pushを使用することに興味があり、エンジニアはLive Reloadを気に入っています。これは、わずかな変更ごとにネイティブアプリをリビルドするのを待つ必要がないためです。

終わりに​

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

ミートアップは、コミュニティの他の開発者と出会い、学ぶ良い機会です。今後、さらに多くのReact Nativeミートアップに参加することを楽しみにしています。もしこれらのいずれかに参加されることがあれば、私を探して、React Nativeをより良く活用するために私たちに何ができるかをお知らせください！