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

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

·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のアプリ内課金フレームワークは、1回限りの消耗型購入と、更新可能なサブスクリプションをサポートしています。もしあなたのアプリが消耗型購入のみをサポートする必要がある場合、クロスプラットフォームライブラリでサブスクリプションのサポートを省略できるかもしれません。

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

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

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

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の使用に慣れると、彼らは喜んでモノレポへの移行を加速させました。

これにより、分割リポジトリのアプローチで抱えていた問題のほとんどが解決されました。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氏のトークの後にもQ&Aセッションがありました。全体として、AirbnbはReact Nativeに満足しています。彼らはCode Pushを使用してApp Storeを経由せずに問題を修正することに興味があり、エンジニアたちはLive Reloadを気に入っています。なぜなら、マイナーな変更のたびにネイティブアプリがリビルドされるのを待つ必要がないからです。

閉会の辞​

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

ミートアップは、コミュニティの他の開発者と出会い、学ぶ良い機会を提供します。今後もReact Nativeのミートアップに参加するのを楽しみにしています。もしこれらのミートアップに参加されたら、ぜひ私を探して、React Nativeをより良くするために何ができるか教えてください！