React現状確認

＠koba04氏は「React現状確認」というタイトルで、現在、Reactの取り巻く状況を様々まとめて語りました。

皆さんご存知の通り、React.jsはFacebookが開発しているJavaScriptライブラリです。まず、Reactはどのようなアプリで利用されているかということからお話します。具体的な例として、まず挙げられるのがFacebookです。ここではバリバリに利用されていますし、Instagramでは、アプリケーション全体がすべてReact.jsで作られていますので、Reactのdevtoolを使って中身を見てみるとなかなか面白いかもしれません。

Netflixではヘビーに利用されていて、テレビのレンダリング部分でも使われています。Twitter(mobile)も、React+Redux+React Routerの構成で利用されています。uberでは最近サイトをリニューアルし、そこでは先の構成にサーバサイドレンダリングなども利用しています。

どのような人がReact.jsを利用しているかというと、パフォーマンスが速いから使っているという人はあまりいない。それよりも宣言的なコンポーネント、ピュアなコンポーネントを定義するためといったことや、メンテナブルなUIを作るために使っている人が多いです。

その他、新しく実装された機能、現状議論されている多くの機能についてコメント。盛りだくさんなので具体的な内容については省略します。詳細な話については、当日の資料をご参照ください。

• Stateless Function Component
• ES2015 Classes & ES2015 Classes Components
• React.createClass
• React.PureComponent
• A pitfall of shouldComponentUpdate
• react-addons-perf
• why-did-you-update
• unstable_batchedUpdates
• ReactElement

最後に、ミーティングが毎週行われていて、ミーティングノートが１週間ごとに出しています。今後のReact.jsはライブラリとしてもっと小さくしていくことや、レンダラー部分についてどう改善していくかなど議論しています。

the-state-of-react-dot-js-2016

なぜReduxを使うのか

＠kuy氏から、最近人気上昇中のReduxについて、Reduxとはどういったものかを語りました。

Reduxが最近注目されている理由は、事例が多くなってきているのと、コミュニティが活発になってきているということが挙げられます。特に開発するための周辺ライブラリが充実し、機運が高まり、Reduxが注目され始めています。

反面、Twitter等でよく見かける投稿は、Reduxがつらい、Redux難しい、Reduxの良さがわからないという意見もあり、結果としてRedux大丈夫なのかと思わせてしまうようなことも起きています。

そこで、なぜReduxを使うのかということを整理してみます。特に、作者のDan Abramovさんいわく、「ライブラリの使い方に時間を費やすよりも背景にあるアイデアを学んで、他所に活用していこう」ということを訴えています。

Fluxは何を解決したのか

Fluxの考え方はご存知の方も多いとは思いますが、順番としてはまず、ViewからActionが投げられます。Dispatherはこの投げられたActionをStoreに投げるルーティングの役割をしています。StoreはActionを受け取ってStateを変更します。このStateの変更をViewが受け取って、Viewはその情報に従ってレンダリングを行うという流れです。

Fluxで解決したかったことは、基本的にはReact単体で構築したときに困ることを解決したかった、具体的には、バケツリレーという問題がありました。バケツリレーというのはコンポーネント階層が深くなったとき、例えば深い階層のコンポーネントへイベントを伝搬するときに、途中のコンポーネントには無関係にも関わらず、通過していくという問題がありました。

Stateをコンポーネントで持っている場合、他のコンポーネントへそのStateを渡したい場合、このコンポーネントの上位の親コンポーネントを作ねばならないという問題があった。何かするときに必ず親コンポーネントを作らないといけない。

Reduxの何がいいのか

FluxにはDispatcherが存在していましたが、ReduxではDispatcherがStoreの中に組み込まれていました。FluxでもStoreがあるが、ReduxではそのStoreを役割ごとに名前を変え、利便性を向上させたところがポイントです。

では、より具体的にReduxのどこがいいのかというと、1つの大きなStateツリーを複数のReducerで構築しています。そして、状態管理だけに特化したところです。反面、それ以外は開発者に丸投げということになりますが、よく言えば開発者の状況に応じて開発できるということを意味します。

そして、状態管理に特化したということがあるので、Reduxを素の状態で利用するのはお勧めできないし、無理してReact, Action, Creator, Reducerで実装すると後で大変な思いをするということです。専用のMiddlewareを入れるといいとのことです。

※当日の資料は以下にアップされていますので、こちらも参照してください。

nazereduxwoshi-ufalseka

Relay

＠hokaccha氏によるRelayのお話です。

RelayはクライアントにReactを利用し、サーバにGraphQLを使ったものです。仕様としてまとめたものがGraphQL Relayで実装としては、react-relayとgraphgl-relayがあります。Relayをひと言で言えば、フルスタックなフレームワークです。Angularがよくフルスタックといわれますが、Angularはクライアントだけなので、Relayはサーバまでやっていますので、本当のフルスタックということになると思います。

GraphQLとは、Facebookが開発したクエリ言語で、クライアント/サーバ間でデータのやり取りに利用されます。レイヤーとしてはREST/RPCと同じ位置付けになります。

RESTと違って、リクエストに対するレスポンスのフィールドが1:1対応しているところです。そうすると、必要なフィールドだけを選択可能となり、ネスとしたデータを一発で抽出できることや、型定義が存在するなどメリットがあります。

Relayの特徴は、そのサイトにも書いてある通り3つあります。

• DECLARATIVE
• COLOCATION
• MUTATIONS

しかし、Relayは敷居が高いと思います。例えば、GraphQLを覚えて、ちょっとしたアプリを作るにもGraphQLのサーバが必要になりいろいろと大変になる。そしてやっている人もあまりいないので、資料を探すとちょっと大変な思いをします。Relayの期待として、真のフルスタックなフレームワークになり、次世代のRailsになれる可能性があるかもしれないかもしれないです。

※当日の資料は以下にアップされていますので、こちらも参照してください。

relay-1

How to style React components

＠Quramy氏からは、コンポーネント内にあるCSSの話がありました。同氏はメインサービスとしてはAngularを使っているが、社内系ツールではReactを使っています。

UI Componentと呼ばれるものの特徴は、見た目と振る舞いがまとめて提供されていて、適度にカプセル化されているものです。そうなると再利用性が高くなり、保守しやすくなるところに期待があります。このコンポーネントは多くのJSフレームワークでサポートされています。

Style定義は、とても壊れやすいです。コンポーネントの外部から、CSSを破壊することが簡単にできるからです。つまり、React.Componentを使っただけでは、CSSが適切にカプセル化されているわけではないのです。この問題は、CSSセレクタがGlobalであることが最大の問題だと言えます。この問題解決のために、

• CSS命名規約
• Web Component(Shadow DOM)
• CSS in JS
• CSS Modules

ということが挙げられます。

CSS in JS

CSS in JSは、Christopher Chedeauが2014年に発表しました。ReactはJSXでテンプレートをJavaScriptに取り込むことに成功したので、CSSもJavaScriptに取り込めばいいのではということから始まりました。CSS class名を利用しないでinline-styleを利用することで、Styleをコンポーネントに閉じ込めることが可能になり、問題の発生がなくなります。

こうした考えは、他にもいくつかメリットがあります。デメリットとしては、擬似要素セレクタや擬似クラスセレクタなど、インラインスタイルで定義できないようなものは利用できません。

CSS Modules

Glen Maddernが2015年に定評しました。CSS in JSはJavaScriptでStyleを生成したのに対し、CSS ModulesはCSSをJavaScriptから利用するというアプローチを取っています。CSSでできることは、CSSでやろうと言ったところです。

CSSで定義された名前を論理名として扱い、JavaScriptでimportし、その定義を読み込みます。JavaScriptが実行されるときに内部的に付与した名前に書き換え、容易に破壊できないようにしています。

※当日の資料は以下にアップされていますので、こちらも参照してください。

react-css-note

Atomic Design powered by React @AbemaTV

五藤佑典氏による＠AbemaTVの事例紹介です。

＠AbemaTVはサイバーエージントとテレビ朝日が共同で展開していて、多様なコンテンツがあります。AbemaTVでは、開発の初めスマホアプリで開発は進んでいましたが、Web版はなく仕様が決まっていませんでした。しかし、リリース日は決まっているという状態でした。

このような状況では、作っていくうちに画面変更が多々入るのがわかっていたので、わかるところから作るという方針でせめて行きました。

画面仕様の変更に強いコンポーネントの粒度を、チームで明確化したいという欲求が出てきました。ATOMIC DESIGNを参考にしました。ATOMIC DESIGNとは、UIコンポーネントの要素を化学の原子論的な要素に見立て、小さいシンプルなコンポーネントを組み合わせより大きなコンポーネントを構成するデザインシステムのことです。

ATOMIC DESIGNの考え方を適用しグローバルナビ、リモコン、スライダー、アイコンなどを作っていきました。こうして作ったAbemaTVの細かな画面変更に関し粒度がある程度細かったため、変更は割とスムーズにできたというところがこのシステムを採用した良い結果だったと考えています。チーム開発において個人の感覚に依存しない形で行えたことは、プロジェクトがうまくいった要素であります。

@AbemaTVはReact+Flux+Atomic Designですが、ViewでReactとAtomic Designを利用し、StoreでImmutable.js、DespatcherでRxJSを使っています。

当日の資料は以下にアップされていますので、こちらも参照してください。

atomic-desigin-powered-by-react-abematv

最後に

このレポートではイベントが盛りだくさんだったため、内容の細かなところまでは記載できませんでした。各登壇者の資料もアップされていますので、合わせて見ていただけると幸いです。また、html5j配信班による動画もありますので、参照してください。

本イベントとは関係ありませんが、2016年のHTML5カンファレンスが9月3日（土）東京電気大学に決まりました！乞うご期待！！