歌舞伎座.tech#6「VirtualDOMとReact」 - connpass に参加して来たのでメモ。

すべてのCSSに死を！これはJSerの叫び！- @kyo_ago

スライド: CSSに死を！これはJSerの叫び！ #kbkz_tech

  • CSSが辛い
  • CSSはカプセル化とか継承とか、プログラムからの概念がそのまま持ってこれない
  • ReactStyle
  • js-next/react-style
  • JS内にStyleを埋め込むことができる
    • そのままオブジェクト的に入れられる
    • Template Stringsと合わせればその場でCSSを入れることができる
    • styles=にスタイルを入れる
  • セレクタをあまり考えなくていい
  • style属性でスタイリングする
  • 擬似要素、擬似クラスが全滅
    • :hover
    • :active
    • などが使えない。
  • CSSの継承などの概念が消える
  • 自分で頑張る必要がある

ユーザプレビュー用LocalProxy - @kyo_ago

  • 非エンジニアのユーザーに対するプレビュー
  • このブランチでDockerとか大変
  • ステージング環境を用意するのが大変
  • アクセス制限やデータ用途が面倒
  • 同時並行で確認できる環境とか作るの大変
  • => ローカルプロキシでURLを別のURLにリダイレクトするプロキシ
  • Chrome拡張で実装したローカルプロキシ
  • 手元のJSやCSSをビルドしたものをどこかにアップロード(Google Driverで管理)、そのリソースのURLをアップロードにしたものへと置き換える。
  • 置き換え設定を吐いて、プロキシに読み込ませる

Dive into React.js - @koba04

スライド: Dive into React.js // Speaker Deck

  • Viewのライブラリ
  • Componentを組み合わせてUIを作る
  • 1wayなデータバインディング
  • React Developer Tools - Chrome ウェブストアを使うとReactのpropsとかComponent見られる
  • VirtualDOMからCanvasを吐いたり、単純なHTML以外でもある
  • Component?とElement?
    • React.createClass が作るのが Component
    • React.createElement でできるのが Element - Virtual DOMの各要素を表す小さなオブジェクト
  • Props
    • Propは外部のインターフェースとなる
    • Componentに何を渡したらいいのかの仕様的な感じ
    • デバッグ時はインターフェースに合わないものを渡すと警告
    • プロダクトだと無害
  • State
    • StateはComponentの状態
    • setStateは非同期に更新される
    • Fluxでループを回してアクセスされることをが前提にあるからかな?
  • Reuseable
    • Componentの役割を意識する
  • VirtualDOMはインフラ
    • 書くときに気にする部分はあんまりきにしない
    • keyをつけるぐらい
  • Componentのライフサイクル
    • 基本的にはこの部分に処理を書いてComponentを書いていく
  • JSX
    • React.createElement のシンタックスシュガー
    • テンプレートらいくなやつ : wix/react-templates
  • react-tools
    • jsxコマンドや変換ライブラリが入ってる
  • Babel(6to5)
    • 元からJSXサポート
  • ref、getDOMNode
    • refはgetDOMNodeと組み合わせて使う
  • dangerouslySetInnerHTML
    • HTMLを直接吐く危険なAPI
  • SyntheticEvent
    • Componentのイベントdelegate
  • How to test
    • React.addons。TestUtilsなどを使ってテストする
    • 基本的にはDOMに追加してテストする
  • rackt/react-router
    • ルーター
    • <Route> isomorphic的なときにも動く
  • サーバサイドレンダリング
    • React.jsではComponentの状態をオブジェクトを持ってるので、HTMLとして吐き出すことができる
    • SEOや初期ロードの時などに活用
  • 実装方法
    • renderToString
      • フロントでもReactを使って動かす
      • reactIdなどの属性がついたHTMLができる
      • クライアントサイドでReactで処理を続ける
  • Flux
  • React.jsは簡単か
    • 基本的にJavaScriptの知識をそのまま使える
  • Reactは開発速度よりもアプリの信頼性を高めることが目的
  • FAQ
    • どこから始めるか?
    • 「VirtualDOMはブラウザが取り込んでいくべきなのかどうか?」
    • 「React.js Advent Calenderで書き残したこと?」

「React/Fluxを実案件で使ってみた」その後 - @t_wada

スライド: 「React / Flux を実案件で使ってみた」その後

  • React / Flux を実案件で使ってみた の続編
  • RendrのAirBnbがReactを使い始めたのがきっかけの一つ
  • Reactをどう勉強したか
    • 公式ドキュメント、チュートリアルが充実してる
    • そのまま写経していって覚えた
  • Flux
  • 実案件で適応したところ
    • 業務システムのやや複雑な管理画面で使った
    • Angularが強い場所
    • Excelみたいな複雑で更新頻度が高いやつ
    • Reactが向いてるのでは? となり使った
  • 開発環境
    • Emacs
    • React + 元祖Flux
    • Browserify
    • npm runでビルド
    • Browserifyみたいなのを使うとモジュールの選び方が変わる
    • underscore.jsみたいな全部入りより、細かいライブラリを合わせて使うようになる。
  • チームにどう伝えたか
    • 最初に画面の各コンポーネントの対応表みたいなものを作った
    • 画面がコンポーネントが構造化されて整理できる
  • 実際に使ってみてどうだったか
    • 富豪的にデータを更新してもレンダリングのコストを心配しなくていい
    • データを渡して全部レンダリングし直すみたいのがVirtualDOMで吸収できて楽ができる
  • はまったところ
    • stateとpropの使い分け
      • 親から渡ってくるものがprop
      • Componentの内部的な状態がstate
    • jQuery UIの置き換え
  • テストについて
    • 公式はJest(jasmineベース)
    • Node.js 0.12/io.js で動かない
    • Jasmine 2とかに対応してない?
    • デフォルトモック, モッキスト
    • 遅い
    • 普通にMocha+assertでも書ける
      • TestUtilsがやってくれる
  • プロパティに触るだけで死ぬパターンがある
    • 観測によってテストが失敗する
    • テスト・ツールがやっちゃいけないこと
  • React/Flux何が良かった
    • サーバサイドみたいなやり方
    • パフォーマンスの問題が起こさずに、データとテンプレートをあわせるだけでできる
    • プログラミングモデルがすごい単純にできる
  • FAQ
    • どれぐらいの規模感
      • でかいフォーム | 右プレビュー
      • 3日ぐらい
    • どれくらいのComponentの分割
      • 細かく分けてもVirtual DOMでコストはまかなえる
      • 細かく分けたほうがテストは書きやすい
      • <div> の入れ子が大体一つのComponentになる感じ
    • Componentの値のやり取り
      • 親子がある場合は親から子へpropを渡す
      • 子のonChangeは親に伝えることができる
      • 再描画したいComponentまでonChangeが渡ったらActionを叩く
      • Storeと同じぐらいの大きさのComponent
        • そのComponentは自分が何をするか知ってる
      • 子のComponentは渡ってきた値を表示するだけ

Real World Virtual DOM - あるいは次世代アプリケーション設計 - @mizchi

スライド: Real World Virtual DOM // Speaker Deck

  • Reactが話題になれば、プロダクションで使えます。
  • Kobito
    • atom-shell版を作った話
  • Qiita(Qiita Team)
  • 同期しないでローカルでも使える
  • 結局Reactとはなんだったのか
    • 単なる「データバインド付きテンプレートエンジン」
  • VirtualDOMとしてのReactの選定理由
    • 情報が十分ある
    • でもちょっとでかい
  • Qiitaへのフィードバック
    • Atom-Shellで作ってるけど
    • 作ったComponentをウェブへ持っていけるかも
  • Atom-Shellで作れるメリット
    • Nodeのモジュールを呼べる
    • Same Originを超えられる
    • デスクトップアプリとして配布できる
    • ブラウザストレージの上限を設定できる
  • 設計時に問題になったこと
  • 問題: JSX
    • JavaScriptの知識を要求しすぎる
      • listをarray.mapで作る
    • AltJSと相性がよくない
    • テンプレート密結合しすぎる
      • ViewModel的な
  • 解決: JSX
    • React-Jade
    • JadeテンプレートをReactの関数に落とす
    • jade と slim 似てる
  • 開発言語
    • UIはReactでCoffeeScript
    • ドメイン層はTypeScriptで書かれてる
  • Flux実装の現実
    • 薄い
    • どの実装もそれな感じ
  • 作った: mizchi/arda
    • Store/View/Dispatcherの塊をContextという単位で管理
    • ReactのState/Propの概念を継承した
    • 位置づけ、Fluxよりもう少し上の概念でMeta-Fluxといってる
  • モジュールを単純に
    • Viewは単なるReactComponent
    • Dispatcherは単なるEventEmitter
    • StoreはEventを受けて状態を更新
  • ContextをTypeScriptで記述できるようにする
    • 型によって仕様を明確にするのが目的
    • ComponentPropsが存在する意味は
    • Componentが知るべき状態を分離したかった
    • Chaplinjs的な分離
    • ComponentPropsが同じなら必ず同じViewを吐く
  • Kobito と Arda
    • ContextはTypeScriptで型で保護する
    • ComponentはCoffeeScriptで雑に書いてEventをdispatcherする
    • Eventの購読側はTypeScripdで書く
  • Isomorphicの実践
    • 同じライブラリがNodeでもブラウザでも動くといい
    • UnitTestはNodeでやりたい
    • 起動コストが高くて不安定なヘッドレスではやりたくない
  • isomorphicのための抽象化
  • ReactのIsomorphic化
    • ブラウザ環境がなくても動く
    • JSDOMを使っても動く
    • componentWillMountまでは呼ばれる(DOM履く直前)
    • document, window, navigator があればReactが動かせる(JSDOMでモックする)
  • Atom-Shellの配布
    • 配布用にビルドしたjsだけにした
    • node_modulesなどには色々はいっててproductにはいらない
  • 実際のReact
    • 画面を変化させまくるときには良い
  • Reactの懸念点
    • サイズがでかい
    • 他のVirtual DOM実装がいったいどれが残るかわからない
  • jQueryとReact
    • 思想レベルで衝突してる
    • jQueryをリードオンリーモードとして使えばいい
  • DOM
    • CodeMirrorみたいなDOMの塊は一つコンテナを用意して入れておく
  • jQueryを使った箇所
    • スクロール量の読み出しと更新
    • 擬似クリックイベントの白化
    • aタグの挙動を全部埋めるハック
  • 大規模SPAの設計
    • ストレージを扱うとデータ管理がシビア
      • ドメイン駆動を意識する
    • RP(Reactive Programming)
  • いいところ
    • Reactは設計が単純化に方向に働く
    • クライアントサイドはisomorphicになっていく

Reactと関数型AltJS

  • Om
  • Elm
  • blaze-html
    • ReactやVirtual-DOMラッパを持つAltJSが増えた
  • jQueryはやんちゃだった
  • AltJSは自己主張が激しい、ReactはViewのみだったので共存できた
  • Reactを関数型AltJSで書く利点
    • Om、elm-htmlは
    • immutableでComponentの更新状態がはっきりする
  • オススメのAltJS
  • ClojureScript
    • Om
  • Elm
    • FRPで有名なElm
  • Scala.js
    • 安定

React + Cordovaでスマホアプリを作る - MASUI

スライド: React + Cordovaで スマホアプリを作る // Speaker Deck

  • チュートリアルはごまかしがきくので何か作って見る
  • 現実に近いところで
  • トレタのみにツールを作って見た話
    • APIを叩いて表示
  • Cordovaを使ってアプリ化する
  • CSSの問題
  • コンポーネント構造
    • 全体でも300行ぐらい

Flowtype - @teppeis

スライド: Flowtype Introduction

  • Facebookが発表したJavaScriptの型チェックツール
  • コンパイル時に静的に方の整合性をチェックすることができる
  • TypeScriptっぽい型注釈
  • 強力な型推論
    • TypeScriptより厳しいチェックする
  • Reactのサポート
    • PropTypesの定義を型をコンパイルチェック
  • ES6 Class with React
  • Flowtypeのコンパイルが早い
    • flowコマンドでバックグランドにプロセス立ち上げて
    • 次から高速
  • Flow vs TypeScript
    • 高速なインクリメンタルコンパイラ
    • Flowはlangじゃない
  • Flowtypeは型チェックだけというレイヤー
    • 型注釈を削ったらそのままJSになる
    • TC39に型注釈の仕様に提案してる
  • はまりポイント
    • 情報がなくて、まだ不安定

Riot.js - @neo6120

  • 独自シンタックスがいいわけじゃなくて
  • それっぽいコンポーネントを書いたら動くのがいい
  • 最近、ランタイムがバグってる
  • Vue.jsが何か意外とよさそうなのでは
  • Riot
  • Vue
  • React
    • でそれぞれ作って比較した
    • emo
  • 求めてたものはvue-componentだったのでは

Fluxの話 - @banana_umai