Flux react現状確認会

20,541 views

Published on

Published in: Business
0 Comments
81 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
20,541
On SlideShare
0
From Embeds
0
Number of Embeds
8,043
Actions
Shares
0
Downloads
48
Comments
0
Likes
81
Embeds 0
No embeds

No notes for slide

Flux react現状確認会

  1. 1. なぜ私はVue.jsを諦め Flux + Reactに 移行したのか ! 社内JavaScript現状確認会
  2. 2. 前提となる適用先 • 管理画面的なWebアプリケーションのリニューアル
 …だったもの(仮) • REST APIを前提としたSingle Page Applicationもどき
 (※すべてが1ページではないけど) • 機能・画面が多い • 複雑化することがほぼ確実
  3. 3. Viewへの要求事項 • 統一されたスタイルでUIとなるHTMLを生成できる • なるべく簡単に書けること(含セキュリティリスク回避)
 (生DOM・jQueryはあり得ない) • 業界におけるパラダイムが過渡期のため、
 巨大フレームワークに乗っかりたくは無い
 (交換可能な部品の組み合わせでプレーンに) • 困ってもなんとか出来るための緊急ハッチも必要
  4. 4. まずFluxを採用した話
  5. 5. What is Flux?
  6. 6. It’s not any framework, is just an architecture.
  7. 7. Flux アーキテクチャ • Facebook提唱のGUIアプリのアーキテクチャ • オブザーバパターンを用いる • データの流れる方向を単一にする • 特定のライブラリに依存する思考ではないと
 解釈している
  8. 8. Flux 概念図 https://github.com/facebook/flux
  9. 9. Fluxのメリット • データの入力と出力のフローが一定になる • 「あるモジュールに入力が起きた場合、次は どこにデータが来るか?」を規約したアーキ テクチャ • なので、デバッグ的な予測がしやすい • MVC方言にありがちな概念の言語化
  10. 10. Fluxの辛いところ • 定着した概念ではないので、オレオレFluxが乱立 している(情報収集の難) • 冗長な箇所もある
 (ほぼ必ずサイクルを一周しなければいけない) • Store->Viewの通知粒度を細かくしないと、
 一般的にViewの更新コストが非常に大きい
  11. 11. 何を使ってViewを
 実装するか?
  12. 12. 今回のViewへの要求事項 • 統一されたスタイルでUIとなるHTMLを生成できる • なるべく簡単に書けること(含XSS回避) • 交換可能な部品の組み合わせでプレーンに. • 困ってもなんとか出来るための緊急ハッチも必要
 (生のDOM APIを触る方法がある)
  13. 13. First, I used Vue.js
  14. 14. ※以後のVue体験記は
 2014年8~9月初頭の、 v0.10.xの印象である
  15. 15. Vue.js (vuejs.org) • Model View ViewModel (MVVM) pattern • ES5でデータバインディングする • Angularのデータバインディングだけ
 切り出したようなもの • イケイケJSライブラリの割に
 ドキュメントが文明的
  16. 16. 「良い」というよりも「楽」 • 宣言的に書ける • データバインディング • データを渡せば勝手に表示してくれる • 紐づければ勝手に更新される • 記述量も少なめ
  17. 17. けれどもな
  18. 18. 個人的にイマイチ感あった • 規約らしいものはあんまりない • 「Vue.jsの考えるViewModel」が言語化されているとは
 言いがたい • 特に値と状態の区別が無いのは好きではない
 (ビュー層の宿命ではあるが) • Vueのテンプレート定義は複雑な記述が面倒くさい • 個人的にJSコードとバインド先の記述の分断を感じる • プロトタイプチェーンを書き換える(※最近、改良された)
  19. 19. プロトタイプチェーンを
 書き換えやがって (^ω^)こういうチェーンがあるじゃろ? ! Hoge   |   V   Hoge.prototype   |   V   Object.prototype
  20. 20. プロトタイプチェーンを
 書き換えやがって (^ω^)Vue.jsにHogeを渡すじゃろ? ! Vue({      data:  {          bar:  Hoge,      },   })
  21. 21. プロトタイプチェーンを
 書き換えやがって (^ω^)Vue.jsはこう書き換えるじゃろ? ! Hoge   |   V   <Vueの変更監視用プロパティ>   |   V   Object.prototype
  22. 22. プロトタイプチェーンを
 書き換えやがって (^ω^)Hoge.prototypeは行方不明じゃろ? ! Hoge   |   V   <Vueの変更監視用プロパティ>   |   V   Object.prototype
  23. 23. プロトタイプチェーンを
 書き換えやがって (^ω^)toString()すらも行方不明じゃろ? ! Hoge   |   V   <Vueの変更監視用プロパティ>   |   V   Object.prototype
  24. 24. ※最近のバージョンで prototype残してくれるらしい
  25. 25. 結局、Vue.jsは断念 • Backbone.Stickitなどからの移行には
 有用ではないかと感じる ! • しかし、2014年秋現在、
 これでゼロから作るかは悩みどころ ! • 生のオブジェクトを扱えないのは悲しい
  26. 26. そうだ、React行こう
  27. 27. React • View特化ライブラリ(render library) • 自動差分描画機能を持つ(Virtual DOM) • データと状態の概念がAPIレベルで
 分かれている • ドキュメントが本当に細かい (github:facebook/react)
  28. 28. 本当のDOMツリー SyntheticEvent
 (Virtual Event) Virtual DOM 差分描画機構 React JS Reactのある生活 ユーザー
  29. 29. Virtual DOM <div>      <h1>bar</h1>
    <p>foo</p>   </div> div h1 p bar foo テンプレートエンジンとして、
 文字列ではなく木構造を作る
  30. 30. div h1 p bar foo div h1 p bar 差分計算の概念図 生成した木構造を中間表現として扱い,
 データ構造としての比較を行う
  31. 31. 本当のDOMツリー SyntheticEvent
 (Virtual Event) Virtual DOM 差分描画機構 React JS データの表示フロー(概略) 人間
  32. 32. 本当のDOMツリー SyntheticEvent
 (Virtual Event) Virtual DOM 差分描画機構 React JS DOMイベントの発生フロー(概略) 人間
  33. 33. Reactのメリット • 実際のDOMの変更処理をReactに丸投げ可能 • 必要なデータを全て一度に入力しても、
 自動で差分が計算されるので、
 常にある程度の速度で描画が可能 • 「参照透過性のあるビュー層」を実現する
  34. 34. Reactのテンプレートの書き方 • JSで React.DOM.Div() みたいな関数を使って 頑張って組む • またはJSX (JavaScript XML)で組む • XMLリテラルぽいが、最終的にプレーン なJSの関数に落とし込まれる
  35. 35. JSX Example (変換前)
  36. 36. JSX Example (変換後)
  37. 37. ReactとFlux • Store->Viewへの変更通知を簡略化できる • Reactでは変更後のデータ一式全てを
 受けても描画コストを抑えられる • 他ライブラリでは、
 丁寧に差分情報を作る必要が有る
  38. 38. Reactのテスト • 公式には「これを使え」というモノは無い • ただしJest(読み込んだものを全部モックに する)というものを公式が超pushしてる
  39. 39. Reactのデメリット • React自身が未だ0.xの状態
 (バージョンアップ時に破壊的変更の可能性) • 枯れてはいない • React管理下のDOMツリーに対して、
 他のライブラリを当てるのは面倒くさそう
  40. 40. なぜReactに飛び移ったのか
  41. 41. 色々あった
  42. 42. Reactを選んだ理由 • 参照透過性のあるビュー = 状態予測可能性が高い • APIレベルでデータの値と状態を分離している • JSXテンプレートがプログラマブル
 (積極的に使いたくは無いけど) • ドキュメントが良い
 (開発元のFacebook自身が使ってる)
  43. 43. ReactでFluxを実践した現状
  44. 44. 1. Store -> Viewの更新通知 • オリジナル
 通知を受けたらStoreから、getterメソッドで 取得してる • 弊プロジェクト
 「そんなことはしない。通知時に一緒にデー タ全部を渡す. StoreとViewを疎に.」
  45. 45. 2. Actionの更新通知 • オリジナル
 リクエスト失敗ケースを考えると、APIリクエスト もAction起因に • 弊プロジェクト
 APIリクエストはStoreの領分なのと、
 サーバーは永続ストレージという認識なので、 Storeに詰め込んだ
  46. 46. 3. テスト • オリジナル
 「Jestでモックすれば楽!」 • 弊プロジェクト
 「モックは実装に立ち入り過ぎ. 静的にできる 範囲で, mochaとpower-assertで.」
  47. 47. 4. Viewのテスト • イベントハンドラの無いViewにユニットテス トは必要ないと判断 • イベントハンドラのテストはしたい • E2Eテストでカバーも考えたい • ほとんどが未着手・検討中
  48. 48. まとめ • 常に気をつけてMVCをやりたくはなかった
 →Fluxを採用した • Viewの更新を楽にしたいし, 
 デバッグもなるべく楽にしたかった
 →Reactを採用した • ReactはView操作のパラダイムシフト
  49. 49. 会場でのQ&Aとか議論とか
 まとめ
  50. 50. Q. Store内部の依存関係の解決は? • Dispatcherが処理順序解決の方法を
 持っているのでそれに頼る(実装依存) • 無かったらメッセージの種類を増やして
 頑張るしかなさそう
  51. 51. Q. ユーザーの入力が複数起きたら? • Fluxの本義に従えば、毎回データフローを回 るべきだし、それで十分に回ると思う • 万が一回らなくなったら、そのとき考える
  52. 52. Q. 「5件メッセージがキューに溜まっ たら更新したい」場合は、どうする? • Store側で適切に閾値を決めて、Viewへの通知 回数を管理すれば良いのでは
  53. 53. Q. jQueryプラグインなどと併せて使 いたい(React移行中のケースなど) •その話は止めろ
  54. 54. Q. どうしてもjQueryプラグインなど と併せて使いたい •そんな事を考えては
 いけない
  55. 55. Q. やっぱりjQueryプラグインなどと 併せて使いたい •本当にそのjQueryプラグ インが必要なのか胸に手を 当てて考え直して、やっぱ り必要だったらReactで 書き直すしかない
  56. 56. Q. Reactに書き直している暇はないんだけど、止むに止まれぬビジネス上の緊急を 要する都合により早急にこのjQueryプラグインを使わなければ死人が出る可能性も 十分にありえる状況において、どうにかしてReactによって統治されたサブツリー内 でjQueryプラグインを使う方法はありますか? • getDOMNode()で生のDOMに触れる + shouldComponentUpdate()を応 用して, jQuery適用対象のDOMをReactに更新させなければ、なんとかい ける、はず
 (やったことないので根拠はない)
  57. 57. Q. アニメーションとかどうする? • ReactがReactCSSTransitionGroupというもの を持っているので、これで対応できるはず • メチャクチャ複雑なことやりたい場合について は、まだ体験した事が無いのでよくわからん • 「絶対に更新されないComponent」を作れば いいんじゃないの?
  58. 58. Q. JSXの名前解決とか • 普通のJSの関数呼び出しに変換されるので、 普通のJSと一緒と考えて良い • React Componentのメンバ関数のthisは,
 各インスタンスにbindされる
  59. 59. Q. Virtual DOMの差分情報は取 れる? • ReactにPublicなAPIとしては現在存在しない • 欲しければ, Matt-Esch/virtual-domを使おう
  60. 60. Q. サーバーサイドでプリレンダリン グしたものにReact当て込みたい • やったことがないのでわからない • API的には出来そうに思えるけど???
  61. 61. Q. Reactの差分描画は最速? • DOM職人には勝てないと思う • 職人エンジニアだけでチームを組まずとも、 生産性を維持しつつ「けっこう速い」ものを
 開発するためのツールと割り切るべきでは

×