一つのdemoでReduxを知る
TodoList小demo
効果の表示
プロジェクトアドレス
トップに戻る(go to top)
データストリーム
データストリームは私たちの行為と応答の抽象です.データストリームを用いることで,reactの状態予測可能な考え方と一致する挙動に対応する応答を明確にすることができる.
一般的なデータ・ストリーム・フレームワークには、Flux/reFlux/Reduxがあります.他のデータ・ストリーム・フレームワークに比べてReduxは軽量(圧縮後2 Kのみ)であり、reactプロジェクトではReduxは単一のステータス・ツリーを維持している.
次に、データ・ストリームを使用する理由を具体的に説明します.
フロントエンドだけでなく、多くのシステム開発時に従うのはMVC分離、つまりデータをModelに入れ、Viewで表示を制御し、Controlerで全体の管理を行う.しかし、システムが膨大になるにつれて、一連の問題が発生します.例えば、例えば、私たちはネットショップを利用して、注文書を提出すると、ユーザーのアカウント、優遇情報、物流情報、在庫などのモデルが更新され、Viewの表示も変化し、逆に、Viewの変化もモデルに影響を与えます.これにより、ユーザーが注文した後、インタフェースがどのように予測できなくなりますか.
そのため、Reactが登場すると同時にFacebookもFluxデータストリーム(Reactは純V層のフレームワークであり、データストリームをサポートする必要がある)を作り出し、その考えは以下の通りである.
ユーザーには様々なアクションがあると考えられ、すべてのアクションが統一されたDispacherによっていくつかのStoreに配布され、このStoreはデータを保存してもページを保存している状態であり、データとページの状態によって、1つのstoreはビューレイヤに情報を伝えるだけで、ビューレイヤが戻ってStoreに作用することを許さず、ビューが更新されます.その後、ユーザーから新しい操作が入力されます.このようにして、ActionがStoreに作用したときに、Viewがどのように変化するかを予測することができます.
そのReduxはFluxの実現方法の一つですが、少し違います.その考えは以下の通りです.
ページレンダリングが完了すると、UIが現れ、ユーザーがUI上のActionをトリガし、ActionがReducerという方法に送られ、ReducerがStoreを更新し、Storeにはreact開発のStateが含まれ、最後にStateがUI層の表示を決定する.これがReduxの完全なプロセスです.
react-reduxインストール:
redux自体はツールフローであり、react-reduxはreduxへのバインドです.同様にng 2-redux、backbone-reduxなどもあります
トップに戻る(go to top)
プロジェクト構造
4つの重要なフォルダ:
--actions:動作
--components:コンポーネント
--container:コンポーネント
--reducer:Storeでアクションを配信する方法
- index.html:テンプレートファイル
- server.js
- webpack
次に、各セクションを例に挙げます(簡単な待機項目の小さなdemo):
Action:(1.行為の抽象である;2.普通のJSオブジェクトである;3.一般的に方法によって生成される;4.typeが1つ必要である)
reducer:(1.応答の抽象;2.純粋な方法(非保存方法は、例えば現在の時間に依存することを指す))
store:(1.actionはstoreに作用する;2.reducerはstoreに従って応答する;3.reduxにとってstoreは唯一である;4.storeは完全なstateを含む;5.stateは完全に予測可能である)
印刷store:
コンポーネント:
効果の表示
プロジェクトアドレス
トップに戻る(go to top)
データストリーム
データストリームは私たちの行為と応答の抽象です.データストリームを用いることで,reactの状態予測可能な考え方と一致する挙動に対応する応答を明確にすることができる.
一般的なデータ・ストリーム・フレームワークには、Flux/reFlux/Reduxがあります.他のデータ・ストリーム・フレームワークに比べてReduxは軽量(圧縮後2 Kのみ)であり、reactプロジェクトではReduxは単一のステータス・ツリーを維持している.
次に、データ・ストリームを使用する理由を具体的に説明します.
フロントエンドだけでなく、多くのシステム開発時に従うのはMVC分離、つまりデータをModelに入れ、Viewで表示を制御し、Controlerで全体の管理を行う.しかし、システムが膨大になるにつれて、一連の問題が発生します.例えば、例えば、私たちはネットショップを利用して、注文書を提出すると、ユーザーのアカウント、優遇情報、物流情報、在庫などのモデルが更新され、Viewの表示も変化し、逆に、Viewの変化もモデルに影響を与えます.これにより、ユーザーが注文した後、インタフェースがどのように予測できなくなりますか.
そのため、Reactが登場すると同時にFacebookもFluxデータストリーム(Reactは純V層のフレームワークであり、データストリームをサポートする必要がある)を作り出し、その考えは以下の通りである.
ユーザーには様々なアクションがあると考えられ、すべてのアクションが統一されたDispacherによっていくつかのStoreに配布され、このStoreはデータを保存してもページを保存している状態であり、データとページの状態によって、1つのstoreはビューレイヤに情報を伝えるだけで、ビューレイヤが戻ってStoreに作用することを許さず、ビューが更新されます.その後、ユーザーから新しい操作が入力されます.このようにして、ActionがStoreに作用したときに、Viewがどのように変化するかを予測することができます.
そのReduxはFluxの実現方法の一つですが、少し違います.その考えは以下の通りです.
ページレンダリングが完了すると、UIが現れ、ユーザーがUI上のActionをトリガし、ActionがReducerという方法に送られ、ReducerがStoreを更新し、Storeにはreact開発のStateが含まれ、最後にStateがUI層の表示を決定する.これがReduxの完全なプロセスです.
react-reduxインストール:
npm install react-redux redux
redux自体はツールフローであり、react-reduxはreduxへのバインドです.同様にng 2-redux、backbone-reduxなどもあります
トップに戻る(go to top)
プロジェクト構造
4つの重要なフォルダ:
--actions:動作
--components:コンポーネント
--container:コンポーネント
--reducer:Storeでアクションを配信する方法
- index.html:テンプレートファイル
- server.js
- webpack
次に、各セクションを例に挙げます(簡単な待機項目の小さなdemo):
Action:(1.行為の抽象である;2.普通のJSオブジェクトである;3.一般的に方法によって生成される;4.typeが1つ必要である)
const addTodo = (text) = > { return { type: 'ADD_TODO', // type
id: nextTodoId++,
text
}
}
reducer:(1.応答の抽象;2.純粋な方法(非保存方法は、例えば現在の時間に依存することを指す))
/* state action state */
const todo = (state, action) => { switch (action.type) { case 'ADD_TODO': return {
id: action.id,
text: action.text,
completed: false //
} case 'TOGGLE_TODO': if (state.id !== action.id) {
return state
}
return Object.assign({}, state, { // state completed
completed: !state.completed
}) default:
return state
}
}
store:(1.actionはstoreに作用する;2.reducerはstoreに従って応答する;3.reduxにとってstoreは唯一である;4.storeは完全なstateを含む;5.stateは完全に予測可能である)
import { createStore } from 'redux'import todoApp from './reducers'let store = createStore(todoApp)
印刷store:
コンポーネント: