React Nativeでの構築中に学んだ教訓

UnsplashのSean Limによる写真

React Nativeでアプリを構築するソフトウェアエンジニアリングの役割の申し出を受けたとき、何を期待するのかわかりませんでした。

一方では、単一のコードベースを使用してiOSおよびAndroid向けのモバイルアプリケーションを構築できることは刺激的でした。一方、Airbnbのような企業がプラットフォームをテストし、最終的にそれに対して決定したと聞いて、かなりの数の課題があると感じました。

今、私は数ヶ月で、ここに私が途中で学んだ教訓のいくつかがあります。

適切なライブラリの選択

React Nativeについて最初に学んだことの1つは、サードパーティライブラリの選択が制限されることが多いことです。 JavaScript Web開発者として、さまざまなプロジェクトにカスタマイズできるライブラリの幅広い選択肢がありました。

React Nativeライブラリの構築はより複雑です。プラットフォーム間で動作するには、iOSとAndroidのネイティブコードの知識が必要です。このため、React Nativeのライブラリを開発する人はそれほど多くありません。

React Nativeにはそれほど多くの選択肢はありません

GitHubでの無駄な検索の後、React Native Communityリポジトリからほとんどのアプリライブラリを選択することになりました。これらは一般に、Reactの最新バージョンでの動作が最もよく維持され、ほぼ保証されています。ネイティブディレクトリは、React Nativeで利用可能なものをすばやく検索するためのもう1つの便利な場所です。

RNコミュニティリポジトリ内であっても、すべてのライブラリがそのまま使用できるわけではありません。時々、レポをフォークして、自分自身でいくつかの調整を行う必要がありました。また、アプリに表示された特定のバグを修正したバージョンにダウングレードする必要がありました。ライブラリとメンテナーが少ない場合、バージョン管理はさらに重要です。

Flexboxに慣れる

Android専用のデバイスは10,000種類以上あるため、すべての画面サイズで機能するアプリを作成するのは難しい場合があります。 iPhone SEほど小さく、Pixel 2XL程度の大きさのデバイスでアプリをきれいに表示する必要がありました。

最初は、React Nativeの組み込みのDimensionsクラスを使用して各画面の幅と高さを見つけることで、アプリのスタイルを設定しようとしました。最終的に、これはアプリが成長するにつれて維持するには複雑すぎました。代わりに、Flexboxは、さまざまな画面サイズのスタイリングに適切に取り組むことができる鍵です。 Flexbox Froggyツールのクイックランは、速度を上げるための良い方法です。

Flexboxは私のスタイリングの問題をすべて解決したわけではありません。それでも、iPhone XシリーズのSafeAreaViewのような独自のスタイリングソリューションを必要とする風変わりな画面サイズに遭遇しました。また、多くの画面で異なるiOSおよびAndroidスタイリングに条件文を使用する必要がありました。ただし、全体として、React Nativeでアプリを設計するための優れたツールです。

オフにしてから再びオンにする

新しいサードパーティライブラリをインストールして反応ネイティブリンクを実行すると、「未定義はオブジェクトではありません」というエラーに遭遇することがよくありました。 React Nativeは、説明のないエラーメッセージで知られています。これが何を意味するのかを理解するのに時間がかかりました。最初は、図書館に何か問題があると思いました。または、インストールしたReact Nativeのバージョンでは動作しませんでした。

次に、特定のライブラリのGitHubの発行スレッドの奥深くで、このコメントが見つかりました。これは、私のライブラリがどれもスムーズに動作しない理由を最終的に明らかにしました。

多くの開発者と同じように、react-native run-androidまたはreact-native run-iosを実行しながら、プロジェクトを単にリロードする習慣になりました。ホットリロードは、アプリに小さなスタイリングの調整を加えて画面をチェックアウトしながら、時間を節約するのに最適です。ただし、新しいライブラリをアプリに統合するのには役立ちません。新しいライブラリは、すべてのシミュレータ/エミュレータを閉じてデバイスを切断し、npm startを再実行してMetroバンドラーを再起動するまで機能しませんでした。

つまり、誤解を招くようなエラーメッセージを表示することなく、サードパーティのライブラリをスムーズに統合するために、すべてをオフにしてから再びオンにする必要がありました。

デバッガなしで作業する

マイクスの写真ペクセルの写真

ウェブ開発者として、私はGoogle Chromeデバッガーでバグを検索する練習をしていました。 React Nativeでは、Chromeでデバッグする能力を失うまで数週間しかかかりませんでした。

私のアプリの制約の1つは、プライマリデータベースとしてRealmを使用する必要があることでした。ただし、RealmにはChromeデバッガーを共食いする問題が頻繁に報告されており、使用できません。別の解決策を見つける必要がありました。

React Nativeには、react-native log-androidまたはreact-native log-iosを使用してconsole.logsを端末に記録できるデバッガーが組み込まれています。これはAndroidでもうまく機能しますが、このデバッガーをiOSで使用すると問題が発生しました。私はAndroidファーストの開発アプローチを採用し始めました。Androidですべてを構築してテストし、console.logsに簡単にアクセスしてから、必要に応じてiOSバージョンを調整します。また、アプリ内でより良いエラーメッセージを書くことに投資しました。これはユーザーと私の両方に利益をもたらしました。

XCodeとAndroid Studioを使用してデバッグすることも試しましたが、最終的には、Androidファーストのアプローチが、画面の切り替えを最小限に抑えた最も簡単なソリューションであることがわかりました。

プロダクションビルドを早期に実行する

経験豊富なReact Native開発者は、本番モードでは、開発でまだ見たり解決したりしていない問題に遭遇することはめったにないと言っています。それは私の経験ではありませんでした。物理デバイスで実稼働ビルドを実行したときに、これまで見たことのないいくつかのエラーを見つけることができました。

レディ、セット、プロダクション

1つの例はナビゲーションです。モバイルアプリでナビゲーションを設定することは、最初は頭を抱えるのが難しいため、適切なタイミングでデータをユーザーに配信するために、反応ナビゲーションライブラリを設定する方法にいくつかの変更を加える必要がありました。物理デバイスを使用すると、ユーザーがアプリを実行するすべての方法(つまり、新しい画面に移動するときと戻るボタンを押すとき)をシミュレートし、それに応じてナビゲーションを設定できます。

本番環境で発見した別の問題には、危険なAndroidの許可が関係していました。新しいAndroidスマートフォンでは、より明示的な許可リクエストが必要です。物理デバイスでテストしたところ、アプリのフォトギャラリーで正しく読み込むにはこれらの許可が必要であることがわかりました。

結論

React Nativeは十分に文書化されており、特にReactを既に知っている場合は比較的簡単に習得できます。単一のコードベースでiOSとAndroidの両方で動作するモバイルアプリケーションを構築することは非常に満足です。

上記で遭遇した課題は、ややこしい部分でしたが、全体として、React Nativeでアプリを開発するのに大きな障害はありませんでした。ほとんどの場合、モバイル開発の癖に頭を包み、いくつかの厄介なエラーメッセージに慣れる必要がありました。これらの最初の学習曲線を通り過ぎて、Androidファーストのアプローチに落ち着いたので、開発はずっと速くなりました。

React Nativeで再度開発しますか?絶対に。