「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
Fluxアーキテクチャに基づいて設計されたReact用フレームワーク
特徴 †
- 上記のFluxの影響を受けていることから、データの流れは一方向になる。
三原則 †
Single source of truth †
状態は一つのStoreのobjectツリーに格納される。
State is read-only †
Actionを発火することが、状態を更新する唯一の方法。
Changes are made with pure functions †
状態がActionによってどのように変更されるか、
定義するために純粋な（副作用のない）Reducerを書く。
ドメイン †
Actions †
- Viewのconnect関数のmapDispatchToProps?引数（デリゲート）で定義・生成される。
Reducers †
- FluxのDispatcherの代替。
- 関数型プログラミングにおいて畳み込み演算を意味する副作用のない関数。
- 初期状態はデフォルト引数で定義される。
- 状態を変更するには、新しいものを合成するように書く。
- 定義（reducer.js
import { ACTION_TYPE } from './actions';
export default (state = {value: 0}, action) => {
switch (action.type) {
case ACTION_TYPE:
return { ...state, value: state.value + action.payload };
default:
return state;
}
}
- 大規模な開発においてReducerを細かく分割する場合は、
combineReducersという関数を用いて書く。
import { combineReducers } from 'redux';
const XXXXReducer = (state = {...json...}, payload) => {
/* 省略 */
};
const YYYYReducer = (state = {...json...}, payload) => {
/* 省略 */
};
const ZZZZReducer = (state = [...json...], payload) => {
/* 省略 */
};
export default combineReducers({
XXXX: XXXXReducer,
YYYY: YYYYReducer,
ZZZZ: ZZZZReducer,
})
Store †
- シングルトンで、インスタンスの管理不要。
- 状態（state）を格納する。
- アプリケーションに必ず1つしか設けらない。
- 1つのStoreですべての状態を管理する。
- イメージとしては「でっかいJSONの塊」。
View †
- Reduxに参加するためにはReactRedux?によって提供されるconnect関数を用いる。
- connect関数のmapStateToProps?引数（デリゲート）は、stateとpropsのバインディングを定義する。
- connect関数のmapDispatchToProps?引数（デリゲート）は、
概要 †
Fluxの場合 †
Reactコンポーネント自身が個別に状態管理をする。
Reduxの場合 †
- 状態管理する専用の場所(Store)で状態管理する。
- Reactコンポーネントはそれを映すだけに徹する。
参考 †
Saga †
概要 †
- Reduxは、最小限で、フルスタックとは言えない薄さ。
（なので、機能を補う幾つかのサブ・プロジェクトがある）
- 副作用を生む処理の設計の指針について、
模索が必要で、その筆頭が 非同期処理の扱いになる。
- 処理をどこに書くのか、
- どのように書くのか、
- どこから呼び出すべきか、
詳細 †
・・・
参考 †
redux-saga †
その他 †
- redux
- redux-thunk
- redux-promise
- react-side-effect
関数型言語の副作用 †
概要 †
- 「戻り値の値」を変えることを「作用」
- 「戻り値以外の値」を変えることを「副作用」
参考 †
ツール類 †
以下のようなツールが存在しているらしい。
Redux DevTools? †
Redux Toolkit †
- 概要
- 手書きでやるのはドMらしいです。
- Ducksスタイルを強要され、後付が困難か？
Reduxの問題点 †
感想 †
- パターン
- ...から外れると途端に（設計/実装に関して）何をしてイイか解らなくなる。
- ...を決めて最小セットを作成してそれに準拠して開発する必要がある。
- やった感想として、
- 複雑でパターン化＆RADのIDEによるサポートが無いと厳しい気がする。
- 早々に、Hooksに行ってしまうのがイイのかも知れない。
参考 †
参考 †
Qiita †
POSTD †
Medium †
terrierscript †
inuscript †
マイクロソフト系技術情報 Wiki †
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
