redux には良い middleware が必須
bouzuya @bouzuya pure な redux におけるほとんど唯一の機能と言っていい reducer の分割だけど、あの思想が全然有効なものだと思えないのは、ぼくだけかな。必要ならその場で簡単に実装できるものだし、基本的に有用ではなくて害ばかりと認識している。 2016-05-24 11:11:38 bouzuya @bouzuya redux の reducer の単位は DDD の aggregate の単位によく似ていると思うのだけど、参照も含めて完全に禁止するあの構造が適切なのか疑問だ。ドメインサービスのようなものを置けないので、容易にアプリケーションサービス相当のミドルウェアに処理が漏れる。 2016-05-24 11:19:51 bouzuya @bouzuya reducer の単位が誤っているのだと言われるかもしれないが、stateの1プロパティではどうしても
Reduxの設計で気をつけるところ - なっく日報
※ Presentational and Container Components - なっく日報 に補足を書きました。 概要 http://rackt.github.io/redux/docs/basics/UsageWithReact.html medium.com らへんに書いてある「Smart Components」「Dumb Components」を理解したよというお話です。 ポイント 以下、個人的な解釈です（ツッコミどころあればどうぞ！） VとCを切り離す ReduxとかFlux系ライブラリへの依存を切り離す あたりがポイントかなと。 VとCを切り離す Reactコンポーネントは 気をつけないと、MVCでいうところのVとCを兼ねた作りになりがち（Fluxアーキテクチャを採ったとしても！） 以下のように別々にわけるとより良い作りになる コントローラ的なコンポーネント（Smart
redux-sagaで非同期処理と戦う - Qiita
はじめに ReduxはSingle Store、immutableなState、副作用のないReducerという３つの原則を掲げたFluxフレームワークです。しかし他のフレームワークと違って提供しているものは最小限で、とてもフルスタックとは言えない薄さです。そのためすべてにおいて定番と言える書き方が定まっているわけでもなく、どうしようか迷ってしまうことも少なくありません。その筆頭とも言えるのが 非同期処理 の扱いです。コミュニティでは今でもさまざまな方向に模索が続いていますが、よく使われているものだとredux-thunk、redux-promiseあたりでしょうか。Reduxに限定しないのであればreact-side-effectというものもあります。こちらはTwitterのモバイルウェブ版で使われていますね。どれを使っても非同期処理が可能になりますが、それはあくまで道具であって、設計の
Read Me | redux-saga
Join the chat at https://gitter.im/yelouafi/redux-saga npm versionredux-saga An alternative Side Effects middleware (aka Asynchronous Actions) for Redux applications. Instead of dispatching Thunks which get handled by the redux-thunk middleware, you create Sagas to gather all your Side Effects logic in a central place. This means application logic lives in 2 places: Reducers are responsible for ha
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
