2016年9月3日に東京電機大学で開催された「HTML5 Conference 2016」のセッションを特集する第二弾は筆者である私、小林徹が登壇した「 Reactの最新動向とベストプラクティス 」の内容を解説します。

Reactの現状

Reactは、2013年にFacebookが公開した、Viewを作るためのJavaScriptのライブラリーです。

• https://facebook.github.io/react/

現在のバージョンはv15.3.2です。 v1.0.0からv14.0.0までのバージョンはありません。 「すでに安定していてプロダクションでも利用できる」ことや「セマンティック・バージョニング（パッチ.マイナー.メジャー）に準拠している」ことを示すために、v0.14.8からのバージョンアップ時にv0.15.0ではなく、マイナーのバージョン番号をメジャーにシフトさせてv15.0.0になりました。

Reactの採用事例を見ていきましょう。

Reactを開発しているFacebookは、ウェブページのコメント欄などで部分的にReactを使用しています。 同じくFacebookが運営しているInstagramでは、ウェブページ全体をReactのComponentで構築しています。

Facebook以外の事例を見てみると、NetflixやTwitter、Airbnb、Uberなど多くの企業でReactが使われています。 日本でも、Abema.tvなど大規模にReactが導入されている事例が増えています。

これらは、ReactのDeveloper Toolsを使用することで確認できます。

• https://github.com/facebook/react-devtools

また、Electron製のターミナルソフトであるHypertermは、ReactとReduxを使って作られています。 機能拡張の仕組みを、Reduxのミドルウェアの仕組みで実現するなど興味深い点も多く、ソースコードはGitHubで公開されています。

• https://github.com/zeit/hyperterm

他にもJenkinsが、新しいUI ComponentをReactのComponentとして提供しているなど、Reactはまさに「今使われているライブラリー」であることが言えます。

特徴

それではまず最初に、Reactの特徴について見ていきましょう。 Reactのサイトのトップには、「Declarative」、「Component-Based」、「Learn Once, Write Anywhere」の3つのキーワードが紹介されています。

「Learn Once, Write Anywhere（一度学べば、どこでも書ける）」は、ReactにとってDOMはreact-domによるただの1つの環境であることを表しています。 react-nativeなどを使うことで、「同じReactの考え方」でiOSやAndroidのような、DOM以外の環境をターゲットにしたアプリケーションを開発できます。

「Write Once, Run Anywhere（一度書けば、どこでも実行できる）」ではないのは、Viewは各プラットフォームのルールや特徴に応じて構築するべきであり、安易に共通化すべきでないことを意味しています。 しかしながらViewに関連しないロジックの多くは共通化できるとしており、実際にFacebookのAds Managerのアプリは、react-nativeを使うことでiOSとAndroidで80%以上のコードが共通化できているそうです。

それでは、DeclarativeとComponent-Basedについて見ていきます。

Declarative

Reactでは、Declarative（宣言的）にComponentを組み合わせてViewを構築します。 宣言的という言葉の通り、状態に対しての「あるべき姿」を宣言するように定義します。

例えば、イベントに対する処理を命令的に記述すると、下記のようになります。

// elに対する変化を書いている
button.on(‘click’, () => el.append(child));

これを宣言的に書くと、下記のようになります。

// render関数は、渡されたstateに対するあるべき表示を定義している
render = state => {
  el.innerHTML = state.map(child => `<div>${child}</div>`).join(‘’);
};

// 状態を更新して、render関数に渡す
button.on(‘click’, () => {
  state.push(child);
  render(state);
};

上記の場合、render関数は受け取ったstateをもとにViewを構築するだけです。 これは、初期表示の場合もイベントによる更新時も常に同じです。

この結果、render関数はstateのみに依存し、同じstateからは常に同じViewを構築します。 これは、テストやデバッグを容易にします。

ReactはComponentを使い、宣言的にViewを構築します。

const View = props => (
    <div>{props.items.map(item => <div>{item}</div>)}</div>
);

Component-Based

Reactでは、Componentを作り、組み合わせることでViewを構築します。 Componentは、Appのようなアプリケーションを全体を表すものから、TextBoxのような既存の要素を少し拡張するようなものまで規模は様々です。

class App extends React.Component {
  constructor(...args) {
    super(...args);
    this.state = {
      text: '',
    };
  }
  render() {
    return (
      <TextBox
        text={this.state.text}
        onChange={text => this.setState({text})}
      />
    );
  }
}
const TextBox = (text, onChange) => (
  <div>
    <input type="text" onChange={e => onChange(e.target.value} />
    <p>{text}</p>
  </div>
);

ReactDOM.render(
  <App />,
  document.getElementById('app')
);

Componentは、View = Component(State)のような、Viewを作る関数として考えることができます。 Componentが返すViewは、ReactElementのツリーとなります。 作成したReactElementのツリーは、ReactDOMによってDOMへと反映されます。 更新時は、更新前のReactElementのツリーと比較して、差分だけがDOMに反映されます。 これがVIRTUAL DOMと呼ばれる部分です。

この差分の反映により、Reactは関数のようにViewの構築を宣言的に書いた場合でも、パフォーマンスの劣化を避けることができます。 先ほど紹介したReactを使わないinnerHTMLによる反映では、毎回DOMを再構築するため、規模が大きくなるとパフォーマンス上問題となります。

Componentの作り方

React Componentの作成方法には、下記の4種類あります。

• Stateless Functional Components
• React.Component
• React.PureComponent
• React.createClass

Stateless Functinal Componenens

関数によるComponentの定義方法です。

const Item = ({item}) => (
  <div>
    <div>{item.name}×{item.count}</div>
  </div>
);

ただの関数であり、インスタンスも持たないのでStateやライフサイクルメソッドが定義できないなどの制限があります。 ですが最もシンプルな定義方法であり、Componentを作成する際は、まず最初にStateless Functional Componentsで定義できないかを考えることをオススメします。

SFCと省略して記述されることもあります。

React.Component

ComponentにStateを持たせたい場合や、ライフサイクルメソッドを使いたい場合にはReact.Componentを使った定義方法を使います。

class App extends React.Component {
  constructor(...args) { 
    super(...args);
    this.state = {
      user: null,
    };
  }
  componentDidMount() {
    fetch('/api/user')
    .then(res => res.json())
    .then(user => this.setState({user}))
    ;
  }
  render() {
    if (this.state.user == null) return <Loading />;
    return (
      <div>
        <User user={this.state.user} />
      </div>
    );
  }
}

React.PureComponent

パフォーマンスが問題となるような場面では、React.Componentの代わりにReact.PureComponentの利用を検討します。 React.PureComponentを使うことで、PropsとStateに対してのshallowEqual(浅い比較)がshouldComponentUpdateに適用されるようになります。

shouldComponentUpdateは、無駄なrenderメソッドの呼び出しを避けるためのライフサイクルメソッドです。

class Counter extends React.PureComponent {
  constructor(...args) {
    super(...args);
    this.state = {count: 0};
  }
  render() {
    return (
      <div>
        <p>{this.props.label}:{this.state.count}</p>
        <button
          onClick={() => this.setState({count: this.state.count + 1})
        />
     </div>
    );
  }
}

React.PureComponentは、PropsやStateのデータをイミュータブルに扱っている場合に利用できます。 イミュータブルであることが保証出来ない場合は、React.Componentを使い、shouldComponentUpdateを自ら実装する必要があります。

ただし、最適化はreact-addons-perfを使い、問題となっている部分を計測して確認してから行うことをオススメします。

React.creteClass

React.createClassは、最初から存在するComponentの作成方法です。 ですが、今後は緩やかに非推奨の方向に進んでいます。

Componentの拡張

Reactでは、Componentの拡張を継承ではなく、Higher Order Components(HOC)を使ったCompositionで行うパターンが推奨されています。

Higher Order Componentsとは、高階関数（Higher Order Function）のComponent版と考えることができます。 Higher Order Functionは関数を引数や戻り値とする関数です。

https://ja.wikipedia.org/wiki/高階関数

• Higher Order Functionの例

// 何かする関数を受け取って、結果をログ出して返す
const logger = operation => (...args) => {
    const result = operation(...args);
    console.log(result);
    return result;
};
const add = logger((a, b) => a + b);
add(10, 20);
// 30

Higher Order Componentsでは、Componentを引数として受け取り、それをラップした新しいComponentを返します。

• Higher Order Componentsの例

// Componentを受け取って、PureComponentでラップして返す
const pure = Component => (
  class Pure extends React.PureComponent {
    render() {
      return <Component ...{this.props}/>;
    }
  }
);
const Item = ({name}) => <div>{name}</div>;
const PureItem = pure(Item);
// <PureItem name=“foo” />

Higher Order Componentsのパターンは、react-routerやreact-reduxなどのライブラリーでも使われています。

また、Higher Order Componentsのパターンを集めたrecomposeというライブラリーもあります。

• https://github.com/acdlite/recompose

// isLoadedによってComponentを出し分ける
const enhance = branch(
  props => props.isLoaded,
  Component => Component,
  () => Loading
);
const LoadUser = enhance(User);
// <LoadUser isLoaded={isLoaded} user={user} />

State管理

Reactでは、ComponentはView = Component(State)であると紹介しました。 したがって、Componentにはなるべく状態を持たせないことが推奨されます。

これにより、親Componentだけに状態管理が集約します。 親Componentは、子Componentに「状態」と「状態を変更するための関数」を渡します。 子以下のComponentは、それらを受け取り利用するだけです。

ViewTree = ComponentTree(State)

親Componentに状態管理が集約されることで、アプリケーションの状態を把握することが容易になります。 それと同時に、子Componentはほとんどロジックを持たず、状態を受け取りViewを構築するStateless Functional Componentsで定義可能なただの関数になります。 これによりテストも容易になります。 加えて、親のComponentは状態管理、子のComponentは見た目に関してと、役割を明確に分けることができます。

しかしながら、このパターンの場合、親Componentに処理が集中するため、規模が大きくなると管理が難しくなります。 その解決方法として、Facebookが発表したFluxというアーキテクチャがあります。

Fluxでは、状態管理の流れを役割ごとに細かく分割し、React Componentから切り離します。

Fluxの影響を受けているライブラリーとして、Reduxがあります。 Reduxは、状態管理のためのライブラリーです。

• http://redux.js.org/

Reduxでは、アプリケーションの状態をシリアライズ可能な1つのオブジェクトにまとめます。 状態の更新は、Actionを発行して、Reducerと呼ばれるActionを元に新しい状態を作成する関数によって行われます。

Reduxでは、React ComponentをContainer ComponentとPresentational Componentの2つの役割に分けます。 それぞれの役割は以下の通りです。

Reduxでは、データはシリアライズ可能なオブジェクトとして単一のStoreに保持されるため、各処理は入力を受け取り入力に応じた結果を出力するただの関数として実装できます。

• アクションの発行 – action = ActionCreator([event])
• 状態の更新 – newState = Reducer(state, action)
• 状態の取得 – props = Selector(state)

これにより、各部分もPresentational Componentのように簡単にテストができます。

状態と処理を切り離し、ActionとStateをシリアライズ可能なオブジェクトにすることは、デバッグや状態の再現を容易にします。 それを利用したRedux DevTools Extensionでは、Actionを記録して任意のActionの流れを再現するだけでなく、指定したActionの流れをJSONとしてインポート・エクスポートできます。 これにより、処理の流れを複数人で共有したり、エラーがあった場合にサーバーに送信することで、状況の再現が可能になります。

• https://github.com/zalmoxisus/redux-devtools-extension

Reduxを使う場合、副作用や非同期処理の扱いを、Middlewareのレイヤーで吸収します。 Middlewareは発行されたActionを改変したり別のActionを発行するなど、アプリケーションの処理に大きく影響を与える部分です。 副作用や非同期処理を扱うためのMiddlewareは、すでにたくさん公開されています。 したがって、アプリケーションの要件に適した、副作用や非同期処理の方法を選択できます。

FluxアーキテクチャやReduxは、必要と感じるまで利用する必要はありません。 ですが、Reduxを使わない場合でも、React ComponentをContainer ComponentとPresentational Componentに分けて考えることは重要です。

エコシステム

Reactでは、すでに多くのエコシステムが存在します。 React Componentのテストを簡単に書くための仕組みを提供してくれるEnzymeや、Component単位でデザインを確認しながら開発できるReact StorybookなどOSSからたくさんのライブラリーやツールが公開されています。

• http://airbnb.io/enzyme/
• https://getstorybook.io/

また、React ComponentやJSXのためのESLintのプラグインも存在します。

• https://github.com/yannickcr/eslint-plugin-react

コーディングのスタイルだけでなく、廃止予定のAPIの使用や、ベストプラクティスに沿っているかなど数多くの観点からのチェックが可能です。 ESLintとともに利用をオススメします。

また、a11yに対するチェックを行うeslint-plugin-jsx-a11yというプラグインもあります。

• https://github.com/evcohen/eslint-plugin-jsx-a11y

将来

Reactは、Facebookが開発しているライブラリーです。 Facebookの内部ではすでに25,000以上のReact Componentがあるそうで、ReactはFacebookの中でも重要な位置付けのライブラリーとなっています。 そのためFacebookが必要としている機能に対する優先度は当然高くなりますが、今後も継続してメンテナンスされることが期待できます。

加えて、OSSとしての役割も重要視されています。 例えば、SVGやcustom elementsの対応のようなFacebookでは必要とされていない機能も必要であればReact本体でサポートされます。 また、ReactのコアチームのミーティングノートをGitHubで公開したり、コマンド1つでReactを使ったアプリケーションの雛型を作成するcreate-react-appもその1つです。

• https://github.com/reactjs/core-notes
• https://github.com/facebookincubator/create-react-app

前述した通り、Facebookだけでなく多くの企業がReactをプロダクションで使用しています。 そのため、Reactは非互換な変更に対してはとても慎重です。

何かAPIを廃止する場合は、「次のメジャーバージョンで警告の出力と移行プランの提供」、「その次のメジャーバージョンで廃止」という流れになります。 したがって、メジャーバージョンアップで突然動作しなくなることがないように配慮されています。

現在進行中の大きな開発として、「ReactFiber」があります。 ReactFiberは、ComponentとRendererがやりとりする、Reactのコアとなるアルゴリズムを全面的に書き直すものです。

現在は、更新処理からReactElementの差分計算・DOMへの反映までが同期的に行われています。 これは、規模の大きなComponentツリーや60FPSが求められるような場面で問題となることがあります。

ReactFiberでは、更新処理をFiberというタスクの単位で非同期に処理できるようになります。 例えば、アニメーションの更新処理など遅延が許されないものは、requestAnimationFrameを使い可能な限りすぐに反映し、APIのレスポンスや画面に表示されてない部分は、requestIdleCallbackを使い多少の遅延を許容するといった具合です。

ReactFiberは、現在ベースとなる部分が実装中であり、すぐに現在のアルゴリズムと置き換えられるものではありません。 しかしながら、今後注目すべき動向の1つです。

まとめ

ReactはComponentを使いViewを構築するためのライブラリーです。 そのためReactが担う範囲は広くありません。しかし、Reactを使うことでクライアントでの状態管理の難しさを排除し、シンプルに考えることができます。

また、Facebookのサイト自体もそうであるように、ReactはSingle Page Applicationではないアプリケーションに対しても、部分的に導入していくことが可能です。 その際に必要となる、設計としては綺麗とは言えないようなAPIも提供しています。

Reactを取り巻くエコシステムは大きくなっており、それらの組み合わせを紹介する記事も多く存在します。

しかしながら、Reactをこれから初めてみようと思っている場合は、最低限の構成で小さく始めることをオススメします。その後、必要だと思った段階で、エコシステムが提供するライブラリーの導入を順番に検討してください。

そうすることで、各ライブラリーが、「何を」問題と考えて「どのように」解決しようとしているのかを理解できるようになります。その結果、多くの情報やライブラリーに振り回されることなく、エコシステムと付き合っていけるようになると考えています。

上記の基調講演は動画でも公開中です

当日の資料と動画は下記で公開されていますので、こちらも参照してください。

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