Fluxに関する独自解釈と妄想を、何かの翻訳っぽく書いた。 スケールするアーキテクチャ フレームワークを作る時、我々は「簡単に記述する」ことを第一に考えがちだ。 そして、簡単にするための仕組みはウケる。 逆に記述量が増えるとウケない。 しかし例外があって、多く書くことによるメリットが受け入れられたときは別だ。 例えば、Backbone.jsを使うと記述量が増える事は誰もが認めるところだが、MVCの実現というメリットのために広く受け入れられた。 要するにトレードオフなのだ。 ここのところFluxアーキテクチャが注目を浴びているが、書いてみると記述量は相当増える。 そもそも登場人物が多すぎる。 Action、Dispatcher、Store、View、それからそれらの間に挟まって仕事をする者達。 一体彼らは何をしたいのか。 最近になって分かってきた。 これはアプリケーションそのものを抽象化した
次期プロダクトでReact.jsを使ってみようと思っていて、その設計をどうすれば良いのかと試行錯誤した結果、それなりにイケてる結論に辿り着いたので、そのメモ書きです。 作ってみれば、Fluxとはこういうことか！というのがわかります。(若干アレンジはされてると思うけど。) それまで漠然と「ふーん、なるほどね。。」みたいな感じでなんとなくしか理解してなかったFluxが実は超画期的なパラダイムシフトであったことに気がついて結構衝撃を受けています。(^^; ちなみにプログラミングの文脈でeと言ったらまず思いつくのがEventかExceptionのどちらかだと思うけど、この場合はもちろんEventのことです。 すべてがExceptionになるのなら、即刻使うのを止めた方が良い。(^^; Fluxとは Fluxの説明では必ずと言って良いほど参照される図なので見たことある人も多いと思うけど、こういうアー
この記事はVirtual DOMアドベントカレンダーの5日目の記事です。 Virtual DOMといえばReact。 ですが、ReactはMVCで言うViewの部分だけを担当するのであって、MVCフレームワーク的なものではありません。 なので、Model等、他の部分は自前でどうにかする必要があります。 そこで、facebookの中の人は、Reactを中心にしたアプリケーション構築パターンとしてFluxってのを提唱してます。 https://facebook.github.io/flux/ Fluxってどんな Flux、ざっくり言うと、 データは1方向に流れる イベントをActionとして定義 ロジック、データはStoreに全部入れる というアーキテクチャ。 図で言うと、MVCでは ↑みたいになるとM,C間の処理の流れムズかったのが、 Fluxだと という風にデータの流れが整理できて嬉しいで
はじめに VirtualDom - なぜ仮想DOMという概念が俺達の魂を震えさせるのか - Qiita を読んでいる前提で話を進めます。 結局”Flux”なんだったのよ 詳細については過去に自分が覚え書きを書いたのでそっちを読んでいただけると良いと思うけど、あれは 「MVCの変形亜種に、オブザーバーパターンを乗せ、データを単一方向に流すことを規定した」ものに、Facebookが命名したものでしかない。極端に目新しいものでもない。その最大の功績はアーキテクチャそのものではなく、「試行錯誤を踏む中で誰もが一度はやっていたであろう似たようなことを上手く実践法則としてまとめた上で、共通認識としての名前をつけた」こと。概念に名前をつけて共有することで、事前説明が簡略化され、本質的な問題に取り組む時間が増える。これをFacebookのブランド力でねじ伏せるように広めたことこそが重要かつ評価すべきポイン
flux-architecture-memo.md Fluxアーキテクチャ覚え書き 参考資料 Flux Application Architecture | React javascript - In Flux architecture, how do you manage Store lifecycle? - Stack Overflow Flux Chat Example React JS › Flux: Actions or ActionCreators Stores and form validation? · Issue #2 · facebook/flux アーキテクチャ本質 ドメインを分割する ドメイン間のやり取りをメッセージパッシングのような疎結合な機構を用いて以下のように行う ユーザーの入力がビューに対して発生したことをロジック側に伝える ロジック処理の結果にデータが変更
2. 前提となる適用先 • 管理画面的なWebアプリケーションのリニューアル …だったもの（仮） • REST APIを前提としたSingle Page Applicationもどき （※すべてが1ページではないけど） • 機能・画面が多い • 複雑化することがほぼ確実 3. Viewへの要求事項 • 統一されたスタイルでUIとなるHTMLを生成できる • なるべく簡単に書けること（含セキュリティリスク回避） （生DOM・jQueryはあり得ない） • 業界におけるパラダイムが過渡期のため、 巨大フレームワークに乗っかりたくは無い （交換可能な部品の組み合わせでプレーンに） • 困ってもなんとか出来るための緊急ハッチも必要
フロントエンド周りの技術は驚異的なスピードで進化し、また多様化しています。それらを全てマスターするのは途方もなく大変なので、ペパボでは、社内のエンジニア・デザイナが「最低限これだけはおさえておこう」というスタンダードを文書化することにいたしました。社内向けを想定した文書ではありますが、社内のみに留めず多くの方に役立てたいと考えたため公開します。 この項目の担当 @hadashiA どうしてフレームワークを使う？ (1) ドメインロジックとプレゼンテーションの分離 (2) SPA（シングルページアプリケーション） 流行り廃り (1) MVC (2) MVVM (3) Virtual DOM どれを使う？ どうしてフレームワークを使う？ (1) ドメインロジックとプレゼンテーションの分離 まずこちらの画面を見てください。 ©任天堂 スーパーマリオワールド スーパーマリオが右にダッシュすると、マ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
