React Context を用いた簡易 Store
課題 redux を引っ張り出すと大仰になる。Context 下に共有ステートを持ってそこに setState できるだけでよい。 なので、次の 2 つを用意する 現在の state を参照する const appState = useAppState() 現在の state を更新する関数を返す const setAppState = useSetAppState() React.useState() と違って分割している理由は、主にパフォーマンス上の理由 大域な参照なので、可能な限りステートを参照したくない setState() の API は (prevState: State) => State も取れるので、状態更新用途に限ってはそもそも useAppState() せずに済むことが多い でも毎回書いてるけどボイラープレート感強い上に忘れるのでここにメモする 毎回書いてるボイラー
Vue.jsにreduxを載せた話｜デロイト トーマツ ウェブサービス株式会社（DWS）公式ブログ
概要 先日とある案件でVue.jsを用いたアプリケーションを開発することとなりました。 一般に同種のフレームワークと比較してVue.jsは、学習コストが低く気軽にはじめやすいということがメリットとして語られています。 ただ、今回の案件のようにMVC系フレームワークを用いて開発する際にネックとなっていたのが、コンポーネント間のデータ共有についての最適解が見つけられていないと感じていたことでした。 もちろん、適切にモデルを設計すればコンポーネント間のやり取りに責任を持つ、親コンポーネントとでもいうべき層を実装することでこの問題は解決できると思います。 しかし実案件では往々にして親コンポーネント層の実装が個々人の裁量に陥りやすく、結果的にコンポーネント間データ共有の方式が統一出来ていないケースも出てきてしまいました。 コンポーネント間で共有したいデータ=アプリケーションの本質となるデータは、もっ
Fluxアーキテクチャのメモ
最近は Flux + React を使っています。Secure Code Tipsでも部分的に採用しました。今回は Fluxアーキテクチャについて、現時点で自分の理解している内容をメモしておきます。 Fluxの概念図Flux: Actions and the Dispatcher | React というページでは以下の図が使用されています。よく見る図です。 現在の自分の認識を基にしてこの図をもう少し詳しくすると、以下になります（だいたいこんな感じという程度の図です）。 * Web API と Web API Utils は省略しています。 Web API と Web API UtilsAction Creators が保持しているメソッド内からAjaxリクエスト処理等を行う場合、その部分をこちらに切り出して使用します。Action Creators と ActionsAction何かしら新
3 ways to integrate Ruby on Rails + React + Flux | Open Minded Innovations
Why I’m using React with Rails I've been using Rails for years and recently I’ve been integrating javascript frameworks into my stack in various ways to help with front end development. There are a lot of great javascript frameworks out there like Angular, Ember, Meteor, etc, but my current favorite is React and Flux. Facebook has been doing tremendous work open sourcing their javascript stack fro
React+FluxでTodoMVCを作ってFluxについて学んでみた - yutaponのブログ
ちょっと前にReactを使って簡単なアプリケーションを作ってみたのですが React入門用に簡単なアプリケーション作ってみる - yutaponのブログ 今回はFluxアーキテクチャについて学びたいと思ったので、TodoMVCを題材に写経してみました。 構成・ロジックは参考にしつつ、ES6構文で書くようにしてます。 参考にしたコードはfacebook/fluxのexamplesのコードになります。 flux/examples/flux-todomvc at master · facebook/flux · GitHub https://github.com/facebook/flux/tree/master/examples/flux-chat 作ったコードはここに置いていて、 https://github.com/sskyu/react-flux-todomvc-example/tree
スケーラブルなプログラミングのために何が必要か - ジンジャー研究室
Fluxに関する独自解釈と妄想を、何かの翻訳っぽく書いた。 スケールするアーキテクチャ フレームワークを作る時、我々は「簡単に記述する」ことを第一に考えがちだ。 そして、簡単にするための仕組みはウケる。 逆に記述量が増えるとウケない。 しかし例外があって、多く書くことによるメリットが受け入れられたときは別だ。 例えば、Backbone.jsを使うと記述量が増える事は誰もが認めるところだが、MVCの実現というメリットのために広く受け入れられた。 要するにトレードオフなのだ。 ここのところFluxアーキテクチャが注目を浴びているが、書いてみると記述量は相当増える。 そもそも登場人物が多すぎる。 Action、Dispatcher、Store、View、それからそれらの間に挟まって仕事をする者達。 一体彼らは何をしたいのか。 最近になって分かってきた。 これはアプリケーションそのものを抽象化した
Fluxなフレームワーク、Fluxxorの紹介 - マルシテイア
この記事は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だと という風にデータの流れが整理できて嬉しいで
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Fluxアーキテクチャの覚え書きを書いた - saneyuki_s log
ReactとFluxのこと // Speaker Deck