ガジェット通信 GetNews

見たことのないものを見に行こう
ワンダーウーマン

「React.js × React Native」―メリット・デメリット、将来はどうなる?【後編】

DATE:
  • ガジェット通信 GetNewsを≫

LT1「Webpackを使ったReact Hot Loaderの導入」

パネルディスカッションの後は、LTタイムに。最初に登壇したのはISAOで社内SNS「Goalous」の開発を行っているフロントおよびサーバサイドエンジニアの吉田将之さん。テーマは「Webpackを使ったReact Hot Loaderの導入」。

Browsersyncとは、ファイル変更を監視して自動でブラウザリロードすることで、一般的に行っているもの。

React Hot Loaderは、Reactの開発においてファイル変更を監視し、ステートを保持したままReactコンポーネントの自動更新を可能にするロードモジュールだと説明。

続いて、テキストボックスに入力した文字列を表示するデモで、どのように使うか紹介した。

1つの親コンポーネントに対して2つの子コンポーネントがある。子コンポーネントを修正すると、その修正は反映されるが、ステートは保持されたままだ。

続いて親のコンポーネントをいじってみる。そこから元に戻す。その際、React Hot Loaderはどのようにそれを実現しているのか。

React Hot LoaderはWebpackなどのビルドツールに組み込んで使うことが前提になる。今回はWebpack、Browsersyncを組み合わせた事例を紹介。

まずは、gulpfileを開く。そしてWebpackConfigでBundlerを作るという手順となる。大事な点はエントリーポイントで、webpackHotDevServerとHotMiddlewareを指定すること。

また複数のエントリーポイントの時にもコツがある。React Hot Loaderはステート保持したまま、コンポーネントを更新できる便利なローダーなので、ぜひ使ってみてほしいとのこと。

LT2「Inside Bdash」

続いて、クックパッドでAndroidを開発しているhokacchaさんが登壇した。テーマは「Inside Bdash」。

Bdashはhokacchaさんが作った、SQLを書いて保存&実行できる、結果を元にグラフを書ける、gistで共有できるというアプリだ。

まずは、アプリのFlux Frameworksのアーキテクチャについて。ドメインロジックの呼び出しをどこでやっているか。描画に関すること以外のすべての処理はドメインロジックとして定義。

データベースのやり取りやAPIの呼び出し、設定の管理など。BdashではドメインロジックはAction Creatorから呼び出すようにしている。

ドメインロジックをFluxのフローから分離したのは、Storeとドメインロジックはテストしやすくなるため。Action Creatorがテストしづらい、すべてがPure Functionというのは幻想なので諦めた。

つまりStateをどう分割するか。リソースごとにStoreをすると、問題になるのは、Store同士の依存関係ができるので、Dispathcerによる交通整理や、waitForを使った依存の解決が必要になる。

一方、ReduxだとSingle Stateなので、Storeを分割しない。Stateを更新する処理を分割するアーキテクチャになっているので、Stateが巨大になるという問題がある。そこでBdashはPage(Container Component)単位で分けてみた。

良い点はStore同士の依存がないこと、Stateをわかりやすい粒度で分割できること、すべてPage単位なのでわかりやすいことだ。

ただ、ページ間でのデータ共有は面倒になる。それを解決するために、Page間で共有するデータはドメインロジック層にストアし、Page切り替えた時に毎回、ドメインロジック層から取り直して更新するという風にしている。

これはサーバーサイドの考え方と同じ。ただ、ストアでできる層がAPIみたいなコストが高い処理だと、ページ切り替え時の処理がもっと複雑になって遅くなるので、あまりよくないと思われる。1ページの処理がすごく多くなったり、複雑なったりするアプリケーションには向かない。

Immutable.jsみたいな豊富な機能も必要ない。ただ、ネストしたStateの更新を簡単にしたいだけ。そこでネストしたStateを簡単に更新する仕組みを作り、Storeに組み込んでいる。BdashはGitHubで公開しているそうなので、参考にしてほしい。

LT3「HyperApp – 1KBのビューライブラリ」

3番目に登壇したのは、Incrementsのエンジニア、Jorge Bucaranさん。テーマは「HyperApp – 1KBのビューライブラリ」。

HyperAppとは2月にリリースした、SPAのフロンドエンドアプリケーションを作るためのJavaScriptライブラリ。React、Preact、Inferno、Ember、Vueなどに似ている。HyperAppはReactと比べると早さは同じぐらい。

なぜ作ったかというと、IncrementsでReactやVueはフレームワークライク過ぎるから。そこで自分が求めるミニマルなVirtual DOMエンジンを作ることにした。

HyperAppのアーキテクチャは3つのメインコンポーネントに分かれる。1つはmodel(アプリケーションデータ)。2つめはacions(アプリケーションのロジック、3つめはView(HTML)。

ユーザーがViewを使ってアクションを起こし、そのアクションでモデルを変更。HyperAppはモデルが変わったことがわかると、Viewをレンダリングするという仕組みとなっている。

HyperAppと他のツールとの違いは次のとおり。まずはdependenciesがない。第二にRedux/Elm的なステート管理を提供していること。第三は300行と短いこと。第四は十分のハイパフォーマンスを提供すること。

HyperAppはViewライブラリを作成し、誰もが理解できるようにするようにするなどして、メインのcontributorに依存しないようにしている。

今後はさらに最適化していくこと、実用例を出していくこと、REPELの作成などに取り組んでいくことを考えている。

LT4「小回りの効くWebViewの使い方」

4番目に登壇したのは地理情報屋のniryuuさん。テーマは「小回りの効くWebViewの使い方」。niryuuさんはネイティブのARアプリを作ることになり、React NativeとWebGLを採用することになったという。

WebViewをネイティブアプリの一部としてガンガン使っていくと、いろいろ問題が出てくる。しかし、情報が散らばっているので調べるのが面倒。そこで今回のスライドにまとめた。ここで扱うのはAndroid(タフパッドのこと)の事例である。

Three.js(WebGL)やOpenLayers(地図)を使いたいと思った。ネイティブでやらない理由は、嫌だったからだ。だからWebViewを使うことにした。最終的にOpenCVなどは出てくるが、そうでない部分は楽にしたかったのだ。

WebViewの使い方(基本)は以下の通り。

これでWebサービスをそのまま載せるとOKである。

assetsから読み込みたい場合。例えばSPAをネイティブアプリの中に埋め込みたいときは、uriをfile://android_asset/以下にすること。

ここで注意しなければならないのは、React Native側のJSのためにbabelとかが設定されているので、WebView側のアセットパイプラインを作るなら、そのへんはうまく避けるようにWebpackなどを設定すること。React Native管理下からの除外はrn-cli.config.jsで行う。

次に、ローカルのストレージに置いた画像や、3Dオブジェクトなどのファイルを読み込みたい場合についての注意点を紹介。
(prop) allowUniversalAccessFromFileURLs={true}をつける(originがfile:///だとajaxが通らないから)。
file://sdcard/から読む。昔から言われているが、良くない方法。

React Native側とやり取りは、アプリケーションの一部をネイティブで、別の部分をWebviewで作って連携させたり、UIはWebviewで作ってネイティブの機能を操作させたりする。またはその逆のやり取りをする。

niryuuさんはCSSが書けなかったので全画面でWebGLをレンダリングし、タッチイベントだけをWebViewで処理。操作系を全部React Nativeのコンポーネントで作った。

ここで問題なのは、3D処理は重いので、WebViewが表示されなくなると、コンポーネントを解法してくれない。この辺はいろいろ試したが、未解決問題となっている。

ネイティブアプリの作り方に近いのではと感じている。React Native側とやり取りについて次の通り。


以前はライブラリを使わないといけなくなったが、昨年10月に実装されている。

PCのChromeからWebViewをインスペクトする場合、ネイティブモジュールを作って無理矢理有効にすると動いた。ただ本質的に難しい点がある。

それは3つの環境(React Native、Android/iOSのネイティブ、Webview)があること。それにより役割分担が必要になるからだ。

React Nativeを使うには、まずはDocsを読む。次にIssuePR、そしてStack Overflowを活用することをお勧めする。

LT5「react nativeでfirebaseのネイティブSDKを操作する」

5番目に登壇したのは、uryyyyyyy(しばたこ)さん。
本業はアドテクでScalaやReactやTypeScriptでWebを作っている。副業でReact Nativeを使っているのだそう。

今回のLTのテーマは「react nativeでfirebaseのネイティブSDKを操作する」。Firebase SDKとGoogle認証を題材に、React NativeでNative APIを扱い、それをSwift/Kotlinでやってみるという。

まずはコードをSwift/Kotlinへ変更する。iOSの場合は、AppDelegateをswiftに書き直す。XX-Bridging-Header.hを用意する。




Androidの場合は、もう少し楽で、ソースコードはシンプルとなっている。

Firebaseを導入する。プロジェクトを作り、アプリケーションを追加。設定ファイルをダウンロードしてアプリに追加し、SDKを入れたりする。

ブリッジ部分の流れは、JavaScriptのソースコードではReact Nativeのソースコードを読ませる。

パッケージに使いたいモジュールを入れると、普通にブリッジができる。また、SDKを触るだけなら言語が詳しくなくてもなんとかなるとのこと。

LT6「Androiderから見るReact Native」

最後に登壇したのは、operandoOS(Shinobu Okano)さん。テーマは「Androiderから見るReact Native」。Androidガチ勢が1週間くらい、React Nativeに触れ合ってみた感想を話してくれた。

React Nativeでいろいろアプリを作った。すべてGitHubに上げているので、どんなものを作ったのか気になった人はぜひチェックを。

React Native1日目の感想としては、Viewがネイティブに落ちたときにどんな風になるか見てみたところ、すべてのViewの頭にReactがついており、Viewを継承した何かになっている。またなんとなく理解できるが、それ以上でもそれ以下でもないと思ったという。

またReact NativeでほしいコンポーネントやAPIの提供については、探さなければならないことがわかった。したがってまずは作りたいアプリを実装する上で必要なViewやAPIはどんなものかを洗い出すこと。そしてそれを実現するコンポーネントやAPI Bridgeが存在するかを調べる。なければ自分で書くしかない。

React Nativeで大変だったことは、公式が提供しているコンポーネントが少ないこと。そして公式のAPIが信用できないことだ。

意外だったことは、JavaScriptやReact.jsの知識がなくても、ネイティブアプリを開発している人なら適当にやってもできてしまうところ。書いているとなんとなくReactになってくるのだ。

React Nativeの魅力に感じた点は、プロジェクト内でネイティブコードとReact Nativeのコードが共存できること。

一部はネイティブのコードでガリガリ実装しつつ、両OSで実装が面倒なところだけReact Nativeで実装できるのだ。つまり、ネイティブの人が実装しても面白くないところはReact Nativeで誰かが実装してくれるというようなことができる。

React Nativeをさらにいい物にするためには、AndroidやiOSエンジニアが頑張ってコンポーネントやAPIブリッジをOSSで作り、公開すること。

課題もある。第一にプラットフォーム固有の動きにどう対応するか。これはネイティブで実装しても悩ましい部分でもある。もしかするとネイティブで実装しろ案件とも言える(笑)。

ただ、React Nativeからアプリ開発が楽しいと思ってくれる可能性もある。楽しくなった人は、ぜひ、JavaやSwiftでも書いてほしい。

これですべてのLTは終了した。ReactとReact Nativeはいずれもこれからの技術。ネイティブアプリを開発している人はReact Nativeを学べばReactを習得でき、そしてWeb開発をしている人はReactを学べば、ネイティブの開発を習得できる可能性がある。ぜひ、関心のある人はチャレンジしてみてはいかがだろう。

⇒【前編】React.js, React Nativeに関するパネルディスカッションを読む

(取材・執筆・撮影:中村仁美)

カテゴリー : デジタル・IT タグ :
CodeIQ MAGAZINEの記事一覧をみる ▶
  • 誤字を発見した方はこちらからご連絡ください。
  • ガジェット通信編集部への情報提供はこちらから
  • 記事内の筆者見解は明示のない限りガジェット通信を代表するものではありません。