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

「イベント」のタグが付いた投稿1件

すべてのタグを表示

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

·9分で読めます
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のシニアソフトウェアエンジニアであるクラレンス・リョン氏が、React Native向けAPI設計に関する講演を行いました。まず、彼が挙げたのは、タブバーやデートピッカーのようなコンポーネントと、カメラロールやアプリ内決済のようなネイティブサービスへのアクセスを提供するライブラリという、主に2種類のライブラリです。React Nativeで使用するライブラリを構築する際には、2つのアプローチがあります。

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

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

アプローチ #1

プラットフォーム固有のコンポーネントの例として、クラレンスは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のリーランド・リチャードソン氏によるものでした。講演は、既存のコードベースでの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氏は、これがバージョン管理サーバーにより高い負荷をかけることになり、小規模な企業にとっては問題になる可能性があると指摘しました。

ナビゲーションの問題​

リーランドの講演の後半は、私にとって非常に重要なトピックである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のようなものでナビゲーションの状態を操作することはできません。

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

閉会の辞​

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

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