CLOSE

React Nativeコミュニティの現在と未来(全2記事)

よく分かるReact Nativeのこれから––GUI上で変更が可能になり、モバイル・Web以外に転用していく

2018年3月23日から24日にかけて、レバレジーズ株式会社が主催する国内最大級のエンジニア向け技術イベント「MANABIYA -teratail Developer Days-」が開催されました。同社が運営するITエンジニア向けのQ&Aフォーラム「teratail」の中で解決できない問題を解くため、一流エンジニアたちが一同に会して、プレゼンテーションやパネルディスカッションを行いました。トークセッション「React Nativeコミュニティの現在と未来」では、React Native JapanのOrganizerである中田一成氏が登壇。React Nativeコミュニティの今日までの軌跡と今後の方向性を解説します。

今はナビゲーション戦国時代

中田一成氏(以下、中田):日本じゃぜんぜん聞かないと思うんですけど、GeekyAntsという会社があります。こういうところが開発しているのは、jsファイルで動作するUIとUXデザインアプリの開発です。

これはReactの流れにも似ているんですけど、結局フロントエンドってデザイナーとエンジニアの協業をいかにスムーズにするかが肝になっていて。

ReactだったらReactのコードからスケッチファイルを出力するみたいなツールもあります。統一的なコードでデザインもWebもReact Nativeもモバイルも開発できるみたいな。かつ、どんどんスムーズに開発していこうという流れがReactコミュニティの中であります。

その流れを担うのがこういうもので、GUI上からReact Nativeの変更が可能になりました。デザイナーがGUI上でちょっといじったら、React Nativeのコードをこんな感じで出力できましたよというかたちで、フロントエンドというか、React Native開発者はサーバーとのやりとりやデータとの関連をメインで開発していく。そういう可能性があるツールかなと思ってます。

あとはBuilderX.ioというJavaScriptの開発と直接連携するような設計ツール。React、React Nativeって最初の設計が肝なんですけど、そういうところを便利にしてくれるツールのリリースですね。あとは単純にboilerplate集を作りましたというところです。

次はWixですね。

Wixはドラッグ&ドロップで簡単にホームページが作れるサービスを提供しているくせに、中はReactを使っているっていう(笑)。わりと矛盾している気がするんですけど。

WixはDetoxっていうend to endのテストツールをリリースしました。実機のサポートをしたりとか、カスタム拡張子のサポートを追加したりとか、アンドロイドに対応したり、並列化したりとか。テストツールとしての使い勝手をどんどん改良してきました。

あとはReact Native Navigationに対して、3人の開発者がフルタイムで開発しているというところ。React Native界隈はまだファクトスタンダードのナビゲーションライブラリが固まってないところがあって。Webで言うとルーターみたいなものなんですけど。

一応公式としているのがReact Navigationというものなんですけど、それも使い勝手があまり良くなくて。現状では、React NavigationかReact Native Navigationの2択という印象です。

そういうナビゲーション戦国時代にある中で、3人の開発者がフルタイムでOSSの開発をしてくれているのは、貢献してもらっているというか、ありがたい部分だと思います。

もしReact Nativeを開発されることがあったら、ナビゲーション周りは気をつけたほうがいいと思います。ただReact Native Navigationって、ネイティブのAPIとか製品のかたちに似かよって作られているんですけど。

逆に言えばネイティブが使ってしまっていて、さっき言ったCode Pushでナビゲーション周りの修正をするときに、うまく動かないといったデメリットはあります。

React NavigationはちゃんとJSで動いているので、リリースしにくいことはないです。ただ、単純に使いにくかったり、ネイティブでやりたかった画面遷移じゃなかったりするので、ここに関してはいろいろ調べてみて、お好きなほうを選んでください。

Reactを書けばなんでも対応する方向性に行っている

あとこれは1月の話だったんで、たぶんこれから直っていくんですけど、React NativeにbundleされているJSCoreを新しくすると、パフォーマンスが40パーセント向上しまっせというのがあります。React Native側もまだまだパフォーマンスが向上していくイメージです。

あとはInfinite Red。これも有名じゃないですけど、いろいろと貢献してくれてます。

reactotronかな? エレクトロンみたいなツールがあって。Reactを書けばデクストップアプリいけますみたいな(笑)。そういうものがあります。

事実上、それをやるとReact NativeとReactのコンポーネントの共通化ができるので、Reactのコンポーネントを開発すればWeb、モバイル、デスクトップアプリなどにいろいろと転用できる。そういう共通化の一歩という印象ですね。

あとはCallstackもそんなに有名ではないですけど、いろいろと細かい改善をしてくれました。

react-native-opentokっていう、WebRTCライブラリのラッパーをReact Nativeで対応する。そういうものをリリースしています。

これはShoutemという会社がShoutemというReact NativeのCMS、React Native版のワードプレスみたいなものを作っていて、それをリリースし改善してます。

簡単にReact Nativeで作ってみたいときは、考えてもいいかもしれないです。

資料にはしてないので、国内の事情をいろいろ話していこうと思います。これからのReact Nativeについてですね。

今までわりとiOS、Androidは統合してきました。統合してきたというかクロスプラットフォームのツールとして使われてきたところがあって、iOS、Androidがいろいろと開発されてきた部分があります。

React Nativeのこれから

じゃあこれからどうなっていくのか? については、大きな流れとしてはモバイルとWeb以外のところに共通化する。例えば、reactotronっていうデスクトップアプリをReactのコンポーネントに書けば作れるようになったり。さらにいろんなプラットフォームに対応していくと思っていて。

一応Facebook本体の開発にReact VRっていうVR対応のライブラリもあったりして。Reactを書けばなんでも対応しますよという方向性に、コミュニティ全体が行っていると思います。

もう1つの流れとしてはReactもそうなんですけど、GUI上でReact Nativeの変更が可能になるところ。デザイナーと開発者がよりインタラクティブに実装していくのは、ReactとReact Nativeともにやっていく流れがあります。

そこでデザイナーからあがってきたものが自動的にコードになる。というか画面自体をデザイナーが作っちゃって、データフローとか接続周りをフロントエンドエンジニアとか、Reactエンジニアが担っていく方向性が理想だと個人的には思います。

コミュニティの方向性としては大きく2つ。デザイナー、エンジニアのよりインタラクティブな開発と、モバイル、Web以外のプラットフォームに転用していくところが大きな流れかなと。

PWAの流れもあると思います。PWAが実際にどれくらい使われ、普及していくのかはまだわからない部分はありつつ、PWAを実装するにしてもReactみたいなかたちで実装しないとPWAに対応できないので。

PWAっていう意味合いでも、PWAをやっていく可能性がある中で、保険としてのReact Nativeはありかなと。PWAが盛り上がろうが、盛り上がらなかろうが、React Nativeは使えるし。もしPWAが盛り上がって、PWAをしたくなったとしても、Reactが使えるのでPWAもできるみたいな。

そういういいとこ取りというか、どっちも選択できる技術なのは、React Nativeの優位性のひとつかなと思っています。

コミュニティとしては、こういうかたちで未来を見据えていると思うんですけど、実際国内のコミュニティとか、採用事例で言うと、さすがにここまでいってることはそんなになくて、わりと地に足がついてるというか。

Webとモバイルとの統合をやり始めているとか、試し始めている企業さんが増えてきているイメージです。さすがにreactotronのようなデスクトップアプリとの統合とかはぜんぜん進んでないんですけど、それより1歩手前のWebとReact Nativeの統合化みたいなところは進めている企業が何点かあります。

当然デザイナーと開発者の統合を進めている企業さんがあって。メルカリさんとかはReactのコードを書けばスケッチファイルにエクスポートできるものを使っていて、それをうまくリリースサイクルに乗せている。リリースサイクルに乗せているというか、うまく確認やデザイナーのやりとりに使っているという記事がブログにあがってました。

そういうところでReactとReact Nativeの統合の採用事例と、エンジニアとデザイナーのやりとりのスムーズ化は、徐々にいろいろな企業さんがやられているようです。

React Nativeにおける細かな注意点

全体的にはこんな感じですね。あとなにか言うことあったかな。5分ちょっとありますけど、質問とかある方いらっしゃいます? 

全体的なことでもいいですし、今回の内容にかかわらずReact Nativeのこういうこと気になってますみたいなざっくりした質問でも大丈夫です。が(会場挙手)

質問者1:(質問聞き取れず)。

中田:込み入った機能を開発したいというか、例えばSNSみたいな機能であれば、そんなに気にする必要はないものだと思ってます。ただ細かいところで、例えばアニメーションの時に60fps出ないとか、どこかのネイティブ機能を持続するときの処理が遅いとかは、別途対応する必要がある可能性はありますね。基本的に感じているうえでは、そんなにネックにはならないですね。

ほかにいらっしゃいますか?

(会場挙手)

質問者2:日本語をうまく使えないので英語でいいですか?

中田:はい。がんばります。

質問者2:(英語で質問)。

中田:ごめんなさい。日本語で回答しますね。質問としては、React Nativeって今後どうなっていって、Flutterとかとどう違っていくのか? ということで合ってますか?

質問者2:はい。

中田:Flutterは自分はあまり使ったことがないんです。ちょっと宣言になっちゃいますけど、6時限目に自分も含めていろんなモバイル開発者とパネルディスカッションをします。そこでFlutterをよく使われているこにふぁーさんという方とも話すので、詳しくはそこでいろいろやりとりできたらなと思ってます。

自分の印象を話すと、Flutter単体に関してはDartを使っていて、Dartって誰も使ってねぇじゃんと個人的には思っていて(笑)。ちょっと政治色を感じるというか。Googleの政治色を感じるところもありますし。

PWAとの兼ね合いも難しいというか。Flutterを使うとDart単体にもなりますし。ちょっと言い忘れてたんですけど、React Nativeって既存のiOSとかAndroidアプリに組み込むことができて。

例えば設定画面だけReact Nativeにしたり、ほかのコアな機能とかメインの機能とかはUXが大事なので、クオリティを求めるためにネイティブで実装していって。

ただ設定画面ってiOS、Androidでそんなに変わらないし、そこにクオリティをがっつり求めないんだったらReact Nativeにしたいよねというときに、部分的にReact Nativeを導入することもできて。そう言う部分はFlutterとは違うと思います。

Flutterはわりと規定のフレームワーク内のデザインというか、規定のデザイン内でいろいろやるのが得意なんですけど。React Nativeに関しては、柔軟にWebでできて、Web、モバイル、あと部分的に入れるとか。そういう部分に特徴があると思います。ありがとうございます。

汎用性高くやっていくには

質問者3:(質問聞き取れず)。

中田:ネイティブ機能をゴリゴリ使うやつ。例えば何だろうな。ビーコンを使うとか。カメラくらいならぜんぜん対応できるんですけど。あとジャイロを使うとか。

なんとかはなるんですけど、けっこう変なバグとかいろいろ踏みそうな。一般的な開発者はあまり使わなさそうな機能ですかね。そういうところを開発しようとすると、React Nativeはちょっときついというか。

結局React Nativeでバグにはまって、ネイティブコードを見る、ネイティブ開発することになりかねないと思うんです。

一般的にSNS機能というか、極端に言ったらWebですかね。Webで対応できそうな機能であれば、ほぼほぼ大丈夫です。一般的なカメラとかよく使われる機能であれば、そんなに問題はないと思います。

あと気をつけるべきこととしては、React Nativeだから100パーセント共通化できるかと言うとそういうわけではない。やろうと思えばできるんですけどね。

やろうと思えばできるんですけど、結局iOS、Android、それぞれのスタイルガイド、デザインガイドがあって、それに沿ったかたちで開発しなきゃいけない。うまいこと共通化していくやり方、ノウハウには気をつけていかなきゃいけないと思います。

画面の最終的なデザインは、それぞれiOS、Androidを作る必要があるんですけど、うまい具合にコンポーネント単位で、このコンポーネントはiOSとAndroidのデザインが一緒だよねとか。あとデザインとは別にちゃんと切り分けて機能のコンポーネントをContainer Componentっていう標準化するコンポーネントをちゃんと分けておいて。

機能に関するデータのやりとりとかに関するコンポーネントは共通化できるようにするとか。共通化するのであれば、そういうやり方を知っておく必要があります。

それをちゃんとやっていくと、Webとか、Reactotronはわかんないですけど、そういう別のプラットフォームに対するときでも汎用性高くやっていけると思います。ありがとうございます。

司会者:以上でセッションを終了いたします。中田様、ありがとうございました。

(会場拍手)

続きを読むには会員登録
(無料)が必要です。

会員登録していただくと、すべての記事が制限なく閲覧でき、
著者フォローや記事の保存機能など、便利な機能がご利用いただけます。

無料会員登録

会員の方はこちら

関連タグ:

この記事のスピーカー

同じログの記事

コミュニティ情報

Brand Topics

Brand Topics

  • 今までとこれからで、エンジニアに求められる「スキル」の違い AI時代のエンジニアの未来と生存戦略のカギとは

人気の記事

新着イベント

ログミーBusinessに
記事掲載しませんか?

イベント・インタビュー・対談 etc.

“編集しない編集”で、
スピーカーの「意図をそのまま」お届け!