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日（土）東京電気大学に決まりました！乞うご期待！！

おはようございます。編集長の白石です。

昨日（2015年4月30日）、isomorphic tokyo meetupに参加してきました。

というのも実は近々、HTML5 Experts.jpでは「Webアプリケーション・アーキテクチャ」に関する特集を行う予定なのですが、そこでキーワードとして挙げられていたのがisomorphic。 サーバサイドとクライアントサイドでコードの共有を促進するのが主な目的の一つ、というところまでは理解できたのですが、実際のところ、アーキテクチャはどう変わるのか？ それを探りたいと思っていたところ、ちょうどよくイベントの開催がアナウンスされていたので、急遽取材させていただきました。

取材を快く受け入れてくださった、主催のYosuke FURUKAWAさん、本当にありがとうございました。

この記事では、トップバッターで講演されていたkoichikさんの講演内容を中心にご紹介して、isomorphicに触れるきっかけとなる記事を目指します。

なお、本日の講演者の皆様による資料はこちらになります。

isomorphic tokyo meetupの発表資料

「Isomorphic Survival Guide」(by koichik)

Isomorphic Survival Guide

「Isomorphic Web development with Scala & Scala.js」(by TanUkkii)

Isomorphic web development with scala and scala.js

「実践isomorphic (+ Electron)」(by mizchi)

実践Isomorphic(+ Electron)

「Unified Interface on Isomorphic JavaScript」 (by axross)

Unified Interface on Isomorphic Javascript

「やみくも isomorphic から抜け出すために足りてないもの」 (by Jxck_)

※資料は後日公開だそうです。

今日のスライドがちょっと片手間すぎるので、公開はいろいろ直してからにします。 #isomorphic_meetup

— Jxck (@Jxck_) 2015, 4月 30

koichikさんによる「Isomorphic Survival Guide」つまみ食いレポート

koichikさんの「Isomorphic Survival Guide」は、まずIsomorphicという言葉の語源からでした。ギリシャ語で「同じ」という意味を表す「isos」という言葉と、「形」という意味を表す「morphe」という言葉を合わせたものだそうです。

isomorphicの語源

同じ成り立ちの言葉として、「metamorphic」や「polymorphic」があるとのこと。オブジェクト指向の世界で頻繁に用いられる「ポリモーフィック」という言葉が、isomorphicと同様「-morphic」で終わる単語だと気づいたのはこの時が初めてで、ハッとしました。

“-morphic”で終わる言葉はほかにも

で、isomorphicが語られるときには、「クライアントとサーバの間でのコード共有」や「フロントエンドとバックエンドの間でのコード共有」と紹介されることが多いですが、そもそもクライアントとフロントエンド、サーバとバックエンドが同じ意味の単語なのか、そこには人による解釈の違いもあれば、指している意味合いの違いもある、と指摘。

クライアント・サーバという用語とフロントエンド・バックエンドという用語は同一ではない

この講演においては、クライアントとサーバはネットワークの「こちら側」と「あちら側」、フロントエンドとバックエンドは情報の入出力を「人間相手に行う」のか「ストレージ相手に行う」のか、という意味で取り扱う。

本講演における用語の定義

例えば90年ごろの「C/Sシステム」（いわゆる「クラサバ」）は、クライアントのWindowsマシン上で「人間向け」（フロントエンド）の処理も「ストレージ向け」（バックエンド）の処理も行われていました。このように、クライアント＝フロントエンド、サーバ＝バックエンドという対応関係は時代によって変遷してきており、J2EEが提唱した三層アーキテクチャやRIAなど、様々なアーキテクチャと製品が模索されてきました。

C/Sシステム

フロントエンドとバックエンドの変遷

isomorphicに挑戦してきた様々なフレームワーク

こうした中、少しでも開発から無駄をなくすために、クライアント／サーバ、フロントエンド／バックエンドの間でコードを共有できないかという可能性が探られてきました。

「isomorphic」という単語は、筆者としては最近になって聞くようになったのですが、実は2011年にリリースされた 「Flatiron」というフレームワークが提唱した概念だったそうです。4年近くも前から使われていた用語だったのですね。

Flatiron

しかし、Flatironはそれほど普及することなく現在に至ります。その後もYahoo!の「Mojito」や、一時期大きな話題になった（今でもアクティブに開発されていますが）Meteorなど、様々なプロダクトがisomorphicなアプローチにチャレンジしてきました。しかしこれらがあまり大きく普及しなかった要因は、「（プロダクト利用者にとっての）どんな課題を解くのか」が不明瞭だったり、ニッチ過ぎたり、先進的すぎたりしたことにあると指摘。

どんな課題を解くのかが重要

そんな中、Airbnbが2013年に公開した「Rendr」 は、SPA (Single Page Application)の「初期表示が遅い」「SEOが弱い」という課題を解決すべく生み出されたもので、 かなり実用的でした。

Rendr(Airbnb)

RendrはBackbone.jsを拡張してisomorphicな環境を実現するものでした。Rendrは、以下のように様々な可能性を切り開きました。

• サーバサイドにおけるフロントエンドレイヤをJavaScriptで提供することで、クライアントとサーバのコード共有を実現しやすい
• サーバサイドにおけるフロントエンドレイヤがセッション管理を行うことで、バックエンドのAPIをステートレスに保つことができる
• サーバサイドにおけるフロントエンドレイヤがAPIゲートウェイとしてデータ変換を行ったり、様々なバックエンドAPIを組み合わせて フロントエンドに提供する（オーケストレーション）ことを可能にする
• 上記のことから、（サーバサイドにおける）フロントエンドとバックエンドの疎結合な関係や、バックエンドの実装をJavaScript に縛られず自由に開発できるようになり、ステートレスなマイクロサービスが協調して一つのサービスを作り上げるという構成を構築しやすい

Rendr的なIsomorphicの可能性

Reactの波に乗れ！

ですが、Rendrがリリースされた時期はAngularJSが人気を獲得した時期と重なっており、残念ながら大きな話題にはなりませんでした…。しかし今、「仮想DOM」というキャッチーなキーワードを引っさげ、Reactが登場するや、非常な人気を博して今に至ります。

Reactの仮想DOM

しかしReactはあくまでビューだけに特化したライブラリ。アプリケーションアーキテクチャとしては、Facebookが 「Flux」を提唱していますが、公式な実装が提供されたのはFluxの一部分 のみであったため、独自実装が乱立する事態となっています。

Flux

Fluxを用いたアプリの基本的な構成は以下のようになります。 フロントエンド部分に限ってみると、処理の流れが綺麗に一方向（unidirectional）になっているのがわかります。

Flux的アプリの基本要素

そして何よりReactが期待されているのは、仮想DOMの仕組みを応用したisomorphicなアーキテクチャ。クライアントでは仮想DOMを実際のDOMツリーに変換しますが、サーバサイドでは仮想DOMからHTML文字列を出力するようにできるので、クライアントとサーバのどちらでも同様のコードが実行できるわけです。

Reactに関係するisomorphicなライブラリには、以下の様なものがあります。

Reactに関係した、Isomorphicなライブラリ

Flummoxも期待のライブラリ。

Flummox

Yahoo!が開発中のFluxibleは、比較的重量級なアプローチの、isomorphicなFluxアプリケーションコンテナ。

Fluxible

Fluxibleが使用する「Fetchr」は、バックエンド（の窓口となるWeb API）へのアクセスを、クライアントサイドとサーバサイドで同様のコードを用いることを実現します。正しくセットアップしていれば、Fluxアプリケーションのisomorphic化を促進できると期待されています。

Fetchr

まとめ

isomorphicなアーキテクチャは長い間模索されていましたが、これまでいまいち波に乗り切れていませんでした。しかし今はReactが非常に人気を博し、isomorphicなアーキテクチャの実現に対して、多くの人々が注力しています。

マイクロサービスとの相性も非常に良いと考えられ、今後大きな潮流になっていくのは間違いないでしょう。

まとめ

Reactの波に乗り遅れるな！