Redux(react-redux)における適切な配列要素の更新
2021年8月23日…
React Native開発の良い点と注意点まとめ
2018年2月28日
React Native開発の良い点と注意点まとめ
本ブログの「React Native開発のつらい点まとめ」が、何気に日本のGoogle検索では検索結果上位にあり(2018年2月28日現在)、1年ほど前の記事が未だに見られているということで、世の中的にはReact Nativeは注目されているんだろうと思う(※本人的には責任を感じており、記事のメンテナンスは今でも続けている)。
つらい点まとめで言及しているように、React Nativeでのネイティブアプリ開発は、少々くせがある。しかしながら、Reactであったり、JavaScript開発経験者にとってはメリットももちろんある。というわけで、React Nativeの良い点と、React Native初見の人が取り扱う上で注意するべき点についてまとめてみた。
良い点まとめ
React Nativeの良い点をざっくり一言でまとめると「React開発者にとってはフレンドリー」に尽きると思う。また、Reactでの開発経験が無くとも、Javascript開発者には親しみやすい。
React開発での知見はほとんどそのまま活かせて開発できる
React Nativeでは、WebでのReactの開発知見をほとんどそのまま活かせる。自分はReact Nativeが最初で、その後にWebでのReact開発を経験したが、それでも移行は問題なかった。React Native開発のキモは、Reactコンポーネントのライフサイクルを押さえることであったり、どのライブラリを組み合わせて開発するかだったりするので、その辺のノウハウがReact開発で既にある人であれば、React Nativeは非常に導入がしやすいといえる。
UIコンポーネントがわりとOSSで公開されていたりする
WebのReact開発でもそうかもしれないが、React Native開発でも複雑な動作を要求するUIだったり、ちょっとしたUIでも多くがOSSとしてインターネット上に公開されている。必要そうなコンポーネントで、公開されているもので使えそうなら使うというのは、React開発者にとってはおなじみだろう。
多くのJavaScriptライブラリがそのまま動く(※WebブラウザのAPIを使っているなどはもちろん無理だが)
一部のライブラリを除き、Javascript開発者がこれまで使ってきた多くのライブラリがReact Native開発でも適用可能だ。冒頭でJavascript開発者に優しい、と表現したのはこの点で、これまでの開発で慣れ親しんだライブラリのセットが導入しやすい環境にある。
Viewの変更→変更後の動作確認がビルドなしでシームレスに確認可能
周辺環境やノウハウではなく、純粋な開発フローという意味でいうと、React Nativeが有する最大利点はコードのHot reloadingである。最近はiOS開発(Objective-C)をしているが、そこでストレスだったのが、Viewのコードをちょっと変更しただけでいちいちビルドをする必要があったことだった(Objective-Cはコンパイラ型言語なので当たり前だが)。React Nativeでは、コードを監視するサーバ(Node.js)が立ち上がっており、コードの変更はシームレスにシミュレータに伝達され、変更後はだいたいのケースで再ビルドをせずとも確認できる。
注意点まとめ
あらためて書き下してみて、つらい点まとめの内容とかぶる。が、あらためて良い点と内容を突き合わせることに意味があると思うので、書いておく。
React Native自体のアップデート頻度がそこそこ早いので、それに追従していかないといけない
React Nativeのアップデート頻度はそこそこあり、2018年2月28日現在の最新安定版は0.53だが、この最新安定版のリリースは約1ヶ月毎に訪れる。基本的には、最新安定版に追従することが推奨だが、使用中のパッケージが該当するかも重要なポイントである(使用パッケージがメンテナンスされ続け、将来性があるかの見極めもまた重要)。
ネイティブ向けに最適化されたルーターが公式から用意されているわけではない
ネイティブアプリ開発では画面表示のルーティング機構は結構キモだと思うが、うまくiOS, Androidの両方のルーティング機構をブリッジしたAPIがReact Native公式から提供されているわけではない。Viewの切り替え機構について公式を参照してみると、react-navigationというルーティングモジュールを使えば良いよ、と案内がある。これも最近ver1.0のリリースがあったような代物なので、実際に使ってはいるものの、ルーターとしての機能での未成熟感は否めないものだ。
React Native公式がOSの機能をブリッジできていなければ、ブリッジしているOSSを探すか、自分で作る必要がある(例：カメラ機能、GPSなど)
案外多くの機能がReact NativeのAPIとしてされていない。React Native公式のドキュメントを一望して、なさそうなら、ない。ないなら探すか、自分で作るしかない。
React Nativeのコードで調整しにくい部分は、各OS向けに出力されたネイティブコードいじろう→できません！！
おそらく他のハイブリッドアプリ開発でもそうだと思うが、React Nativeでは基本的にはビルドされたコードを調整することはできない。React Nativeによって生成される各プラットフォーム向けのプロジェクトファイルを見ると、Viewのコードに着目した場合、AndroidでいうActivityはMainActivity1つだし、iOSでもViewらしいコードは後述AppDelegateクラスにてViewの表示の記述が1箇所あるのみだ。
iOSのコードでは、実際のReact Nativeによる挙動はAppDelegateクラスで行われている。AppDelegateクラスの実装部では、Reactモジュールをロードしており、Reactクラス、RCTRootViewのインスタンスを、最終的にiOS標準のViewの表示系統を担うクラスのUIViewControllerクラスより生成したインスタンスにセットすることで、画面描画をしている。
また、RCTRootViewインスタンスでは、下記のように実際のJavaScriptコードのエントリポイント(index.js)を参照するような記述がある。
jsCodeLocation = [[RCTBundleURLProvider sharedSettings] jsBundleURLForBundleRoot:@"index" fallbackResource:nil];
よって、このiOS向けのコードの実装から分かるように、React NativeではOSネイティブのコード上ではあくまで「1枚のスクリーン」しかない。よって、react-navigationのようなルーター機能を持つパッケージを適用したところで、画面遷移が「遷移しているっぽく」は見えるが、iOSネイティブコード上の動作では、画はあくまで1枚しかない。
React Nativeは、まだ1.0リリースではない(2018年)
React Nativeは注目度は高いようだが、まだバージョン1.0を迎えていない。そのため、大きな変更が積極的に行われることも考えられる。個人的な感覚だと、枯れこそいないが、1.0リリースの前に変に盛り上がって、1.0になる頃にはビミョーっていう扱いになっていないかが気がかりだ。
ここ最近のReact Nativeの大きな進展でいうと開発環境にExpoの採用をしたくらいで(この記事には書いていないが、Expo自体の仕組みもだいぶ面白い。QRコードをExpoアプリで読み込むと、QRコードに該当するアプリがビルドされる)、未だプッシュ通知のAPIがAndroidは対応していなかったり、公式提供のAPIが中途半端な感じは否めない。
初回ビルドがマシンによってはかなり遅い。40〜50分ほどかかる場合も
自分のマシンはMacbook(Early 2016)でCPUとメモリをスペックアップしたものだが、このマシンでビルドをすると、40分以上、50分未満の時間がかかっな。その後のビルドは10秒いくかいかないかと、早いのだが、この初回のビルドがやたら遅い点は気がかりだ。ちなみに知人のそこそこ良い開発マシンでもReact Nativeビルドの最速タイムは10分だったそうで、なんだかんだ時間はかかる模様。
つらい点、良い点、注意点ときたが、実際にはReact Nativeはありなのか
React Native開発はあり・なしの二者択一でいうと、もごもごしてしまうが、ケースバイケースだと思う。
例えばダメなケースの例で、製品レベルで使用する前提の話で、要件が複雑なアプリを作ろうとし、その際Web開発者しかいないチームで使うのは絶対にダメだと思う。なぜなら、ネイティブAPIでReact Native公式がAPIをラップしていない、第三者の提供のモジュールが微妙だったり、存在しない。そういったケースの際にわりとWeb開発者のみで構成されたチームだと、詰みやすかったり、調査・開発コストが大幅に増加するからだ(経験済み)。
要件が複雑なアプリを作るにあたり、例えばチームにiOSだったりAndroid開発者がいて、React Nativeへのブリッジを書けるとか、詰まった時になんとかなる状況ならReact Nativeは採用しやすいとは思う。
あとは、逆にReact Nativeを使いやすい・活かしやすい条件としては、モックアップだったり、使い捨て前提のプロトタイプであるとか、APIにリクエストを送って、画面の表示変更が起こるだけの単純なアプリなら向いていると言える。
Viewの表示変更については、Reactが最も得意とするところであり、特に描画の遅延だとか、今のところ、変なことは感じずに良く動いてくれる。react-navigationは、すごく使いやすいルーターとは言えないが、React開発でreact-routerなどを扱ったことがある人なら問題なく扱えるものとなっている。画面の遷移も、少し前まで標準的なルーターとして使われていたと思われるreact-native-router-fluxより標準的な設定でもだいぶキレイな感じがする。要件がViewの表示切り替えのように単純であるのであれば、Web開発者のみのチームでもやっていけると思う。その際、Reactのノウハウがあれば開発効率は良いと思う。
React Native開発を気ままにやっている身としては、要件な複雑なアプリを作る際には基本的にはサードパーティのモジュールに依存することが多く、React Nativeは未だ安定していないという認識だ。React Nativeはまだまだ発展途上のプラットフォーという認識なので(2018年2月28日現在、v1.0に達していない)、現行バージョンを製品レベルで採用し、本気で数年スパンで考えて使えか得るのか？というと微妙だと思う。とはいえ、ハイブリッドアプリ開発のジャンルでいうと、かなり注目度が高いプラットフォームではあるので、特性を理解し、まずは前述のような「ある程度わりきった使い方」で付き合えると、良いのではないかと思う。
蛇足だが、自分が最新技術のトレンドの参考の指標にしているHacker News Hiring Trendsというサイトがある。ここではReactの求人がやけにシリコンバレーエリアで伸びていそうなことが確認できる(2018年2月度)。このエリアには小さい規模のスタートアップが多いと思うし、ReactでWeb作って、似たような技術のReact Nativeでネイティブアプリ作って、とクライアントサイドの技術セットをReact合わせて、さっさと作りたい場合にはReact Nativeは重宝されているんじゃないかな〜と少し想像してしまった。たぶん、このエリアのスタートアップの考え方だと「資金ができてきたら作り変えるから、動くものをさっさと作れ！」の精神だと思うが。
タグ: React Native, 良い点
Discussion about this post