EVENT REPORTイベントレポート
ヒカラボレポートとは、開催されたヒカラボにおいて、登壇者が伝えたい講演内容を記事としてまとめたものです。ご参加された方はもちろん、ヒカラボに興味があるという方も是非ご覧ください。
ヒカラボレポートとは、開催されたヒカラボにおいて、登壇者が伝えたい講演内容を記事としてまとめたものです。ご参加された方はもちろん、ヒカラボに興味があるという方も是非ご覧ください。
イベントレポートvol.11
2016/10/03(月)更新2016/08/25(木)19:30~21:30
Facebookが提供しているJavaScriptライブラリ・React.js。今や「Yahoo!」や「Airbnb」「Netflix」などの有名サービスなどで採用されています。
2016年8月25日にヒカ☆ラボを開催。webメディア「SELECK」の運営をはじめ、複数の事業を展開するリレーションズ株式会社での活用事例にもとづき、React.jsとその周辺技術について。今回の当日の模様をピックアップしてお伝えします。
講演者プロフィール
講演者プロフィール
講演者プロフィール
最初に登壇したのは、リレーションズが運営するwebメディア「SELECK」でリードエンジニア兼編集部員を務める諸見里氏。同サービスのインフラからフロントまでを担当しつつ、取材や記事の執筆までもこなしているといいます。そんな諸見里氏は、React.jsの概要から「SELECK」での活用事例までをレクチャーしてくれました。
まず諸見里氏は、React.jsの概要をつかむためのキーワードとして「コンポーネント指向」「JSX」「Sever Side Rendering(SSR)」「VirtualDOM」「Flux」といったワードをピックアップ。今回の講演では触れられなかった「VirtualDOM」以外のワードについて解説しました。
■コンポーネント指向
コンポーネント指向とは、画面のパーツのコンポーネントに分けるという概念。ここでは「SELECK」の画面を例に、コンポーネントをヘッダー、サイドバー、カードといったパーツに区切っていく考え方だとざっくり説明。React.jsは、コンポーネント指向に基づくライブラリだと述べます。
■JSX
コンポーネント指向を実現するための仕組みのひとつがJSXであり、「JavaScriptのコードの中に、HTMLライクなViewを書く仕組み」だといいます。
■Server Side Rendering(SSR)
JSXに関連して、SSRについても説明。これはRuby on Railsにおけるhamlといったテンプレートエンジンを置き換えるものだとし、ここではさらっと触れるに留まりました。
■Flux
React.jsはView周りの完成度は高い一方で、その他のアプリケーション部分には関与しないという面があるそうです。React.jsの欠点を埋める、データフローのためのアーキテクチャがFlux、Reduxはそのフレームワークであると説明します。
次に諸見里氏が述べたのは、「SELECK」でReact.jsを採用した理由について。一般的にはReact.jsを採用する理由として、「『VirtualDOM』で差分を更新するためViewの更新が速い」というものがあるそうですが、webメディアである「SELECK」はフロントのロジックが薄いため、あまり恩恵がないそうです。また、管理画面にもReact.jsを使っているそうですが、やはりスピードは重要ではありません。
それにも関わらず、「SERECK」でReact.jsを採用している理由として、「SSRでのViewの一元管理」「コンポーネント指向、Fluxによる共通認識」「Universal(React Native)」「流行っている」という点を挙げました。
そこから「SELECK」での事例を基に活用法を解説。webメディアはSEOの観点から、シングルページアプリケーションにできないのだといいます。サーチエンジンに拾ってもらうためには、Viewをレンダリングせずに、サーバーサイドからフロントへHTMLを返す必要があると。この問題に対して、テンプレートエンジンを使った場合は「コード上におけるViewの管理が二箇所に分かれる」のに対し、React.jsを使えば共通のコンポーネントで行えるのだそうです。
続いて諸見里氏は、React.jsを使用した上で辛く感じたところにも触れました。
■サイズが軽くない
単純にReact.jsのファイルが重いことに加え、SSRする際は初期データもレスポンスに含まれるというのが気になったそうです。この対策として、React.jsと関係ないと前置きしつつ、「全ページまとめてバンドルしていたものを、ページごとに分割」「Webpackでビルドする際に、NODE_ENVでproductionにしておき、デバッグ用のコードを削る」「lodashやbluebirdといったライブラリを極力を使わないように対応」と述べました。
■style-loaderが使いづらい
style-loaderは「CSS in JS」の仕組みの1つで、コンポーネント内でCSSを読み込むための機能だそうですが、諸見里氏はこのstyle-loaderが使いづらいと感じたそうです。SSRではNode.js側でコンポーネントを読んでHTMLを吐き出しているのですが、Node.js自体はCSSをモジュールとして読み込む機能を備えていないので、エラーが出てしまうのだとか。
■フロントビルド時にWebpackのmodulesDirectoriesが使えない
フロントビルドする際、WebpackのmodulesDirectoriesが使えない点も辛いと感じた点として述べます。Node.jsのモジュールローダーはWebpackのconfigを読まないため、Node.jsが起動できなくなるといいます。
諸見里氏は、style-loaderとmoduleDirectoriesについて解決できるモジュールも見つけたそうですが、あまり信用できないモジュールを入れたくないと考えた結果、style-loaderとmodulesDirectoriesを使用せずに対応したそうです。
ここまで述べた上で、諸見里氏はReact.js自体はすごくシンプルだとしつつも、React.jsを使う上ではWebpack、babel、Reduxなどの周辺技術の理解までも求められるため、使用するハードルが上がっているのだろうと見解を述べました。とはいえ、ライブラリの数や情報量など、流行っているがゆえのメリットがあるため、「個人的にはAngular2などを使いたいが、ビジネスで使うならReact.jsになる」と締めくくりました。
2番目に登壇した奥宮氏が講演した内容は、React.jsの仕組みでネイティブアプリと遜色のないパフォーマンスのモバイルアプリが開発できるというフレームワーク「React Native」について。リレーションズではモバイルアプリ開発専門のエンジニアがいなかったため「今あるリソースでアプリ開発ができないか」というところから、React Nativeを採用したそうです。リレーションズが運営するサービス「スマートメンテ」の開発事例に基づいた内容をレクチャーしてくださいました。
奥宮氏は最初にReact Nativeの特色について述べ、コンポーネント指向やJSXといったReact.jsの考え方・技術を使って、iOS・Androidのモバイルアプリをクロスプラットフォーム開発が出来る可能性を特徴のひとつとして挙げます。また、現在は2週間に1回程度のペースでバージョンアップが行われているという点や著名なサービスでも注目されているという点にも触れ、盛り上がりを見せているフレームワークだと解説しました。
React NativeはFacebookをはじめ、NetflixやAirbnbなど、さまざまなアプリに用いられているという
次に「React.jsの仕組みでモバイルアプリが作れる」という点について、下記のようなスライドで解説。「ES6,7といった新しめのJavaScriptで書ける」「コンポーネント指向やJSXなど、React.jsの考え方・技術が使える」などの点を挙げ、React.jsの作法が流用できる部分が多いのだといいます。
公式のチュートリアルにあるサンプルコードを用いて、React Nativeでの書き方も解説
続いて奥宮氏は「React Nativeは描画のパフォーマンスがいい」という点について、「JavaScriptでコードを書くが、実際のUIはネイティブのコードで実行する」という点を挙げて説明します。たとえばCordovaなどのハイブリッドなフレームワークを使ってWebViewでモバイルアプリを作った場合、APIでネイティブのコンポーネントにアクセスする形になり、パフォーマンス面での制約になるといいます。
React Nativeではさまざまなネイティブコンポーネントが用意されており、JSXのタグで書けばそれらにアクセスできるといいます。ただし、用意されていないものもあり、そういった場合は「ネイティブモジュールを自作する」か「サードパーティのnpmを利用する」ことになると付け加えました。
また、iOSとAndroidとではネイティブのコンポーネントに違いがあることもあり、それぞれでコードを書き分けなければならないとこもあるのだとか。この点については、「Cordova/WebViewのように1つのソースでブラウザコンポーネント上で動くという点を取るのか」「React Nativeを使ってコードを書く手間がかかってもパフォーマンスがいい方を取るのか」というような選択のしどころだとしています。奥宮氏自身は、かかる手間と受ける恩恵を比較して、恩恵の方が大きいと感じているそうです。
次に奥宮氏はReact Nativeでの使用感について述べました。基本的には、webエンジニアでもモバイルアプリ開発が行えるという利点に満足だそうですが、React Nativeでの開発事例が世間にはあまりないため、情報が少ないことに苦労したともいいます。
また、バージョンアップが頻繁に行われているため、「それまで使っていたnpmパッケージ対応しなくなる」といったケースもあり、その対応にコストがかかることにも言及。この点に関して、実際にアプリをリリースしようと決めた場合はバージョンを固定して、開発を行っていくのがいいだろうと述べました。
続いて、JavaScriptのコードを書けばiOSでもAndroidでも動くクロスプラットフォームではあるものの、これは完璧ではないともいいます。特にiOSと比べ、Android側のネイティブコンポーネントのリリースが遅いという傾向があるそうで、やはり対応に手間がかかったのだとか。
他にも、「redux-api-middleware(npmパッケージ)がAndroidシミュレータでは動いたものの、実機では動かなかった」という「スマートメンテ」での事例を挙げ、あくまで開発途上のフレームワークであることを踏まえた上で開発を行っていくのがいいだろうということです。
最後に事例として挙げたのは、React.jsとの共通化について。「スマートメンテ」はweb版とアプリ版とで、ユーザーや利用できる機能に若干の違いがあるそうで、Viewは別々のものなのだとか。とはいえ、できるだけ共通化をしたいということで、「データモデル」「API接続まわり」「表示用データ整形などのロジック」などのViewに依存しない部分を切り出したといいます。
リポジトリをwebとネイティブで分けたのは、メンテの負担を軽くするためなのだとか
ここまで述べた上で、React Native はReact.js経験者なら気軽にモバイルアプリが開発できるという点を奥宮氏は再度述べました。ただし、Cordovaのようなwebベースのハイブリッドなフレームワークを利用した場合と比べて、各プラットフォームへ対応させるための工数はそれなりにかかるといいます。そのぶん、パフォーマンスや機能は充実しているため、状況に合わせて判断してほしいとのこと。
最後に、奥宮氏は「React.jsのコードをそのままReact Nativeに使えるわけではない」という点に触れ、共通化できる部分もあるが、基本的にはViewはwebとアプリで別々に作る必要があると締めくくりました。
最後に登壇したのは、リレーションズに7月まで参画していたというフリーランスエンジニアの中田一成氏。リレーションズではフロントエンドを担当し、React.jsやReact Nativeを使っていたという中田氏は、React.jsの最新動向というテーマで発表してくれました。
中田氏はまず、React.jsの経緯を初期・中期・後期の3つに分けて説明。React.jsはFacebook社製のフレームワークであり、リリースされた当初、使い方に関してはユーザーに丸投げに近い形だったといいます。それはReact.jsでのデータフローについてのアーキテクチャであるFluxでも、同様だそうです。
中期ではそういった流れを受けて、より開発をしやすいようにエンジニアたちが自作したツールが出てきたといいます。諸見里氏、奥宮氏の講演でも触れたReduxやreact-routerなども、これに該当するだろうとしています。
その後、Facebookからcreate-react-appというリポジトリが提供され、React.jsを学びやすくなったといいます。React.jsを始めようとした場合、それまではES6やWebpackなどの各種ツールを使用し、さまざまな設定をしないと実質的には使えなかったという点が、JavaScriptに馴染みが薄い人にとっての壁になっていたことを中田氏は指摘。create-react-appは、React.jsで開発するためのハードルを下げたと説明します。
また補足として、FacebookにReact.jsを学びやすい環境を提供するクリエイティブチームが作られたという点にも触れ「近いうちに何らかの告知やリリースがあるのでは」と推測していました。
次に中田氏はFacebookが提供しているRelayというツールを解説。同ツールを使えばFluxに基づいたデータフローの流れを簡略化できるそうです。RelayにはGraphQL(Facebookが開発したクエリ言語)が用いられており、APIをサーバーサイドに実装せずとも、データベースにクエリを投げるだけでフロントエンドに返ってくるデータが変わるという点がメリットのひとつだといいます。
一方で、Relayを利用する場合にサーバーサイドが対応している必要があるため、コードを書き換える必要があるほか、MySQLにおけるオフセットの機能が現時点では実装されていない、などの問題も指摘。1年ほど経てば、こなれてくるのではと推測します。
そのほかにも、React NativeやReason(Ocamlのラッパー)といったツールにも触れ、Facebookが行っている「Re●●」といったプロジェクトを追っていけば、React.jsの最新動向をつかみやすくなるとコツを教えてくれました。
発表の最後では、フロントエンドの動向について、「手軽にサービス開発が始められるフレームワークが広まるのでは」という見解を述べました。その点を踏まえ、現状ではReact.jsでの開発で重要なFluxやReduxなどを理解するためのハードルが高いので、環境設定などを飛ばして開発を始められるようなツールが出れば、React.jsが広まっていだろうと締めくくりました。