Angular2和Rx的相關知識可以看我的Angular 2.0 從0到1系列
第一節：Angular 2.0 從0到1 （一）
第二節：Angular 2.0 從0到1 （二）
第三節：Angular 2.0 從0到1 （三）
第四節：Angular 2.0 從0到1 （四）
第五節：Angular 2.0 從0到1 （五）
第六節：Angular 2.0 從0到1 （六）
第七節：Angular 2.0 從0到1 （七）
第八節：Angular 2.0 從0到1 （八）
番外：Angular 2.0 從0到1 Rx—隱藏在Angular 2.x中利劍
番外：Angular 2.0 從0到1 Rx—Redux你的Angular 2應用

標題寫錯了吧，是React吧？沒錯，你沒看錯，就是Angular2。如果說RxJS是Angular2開發中的倚天劍，那么Redux就是屠龍刀了。而且這兩種神兵利器都是不依賴于平臺的，左手倚天右手屠龍……算了，先不YY了，回到正題。

Redux目前越來越火，已經成了React開發中的事實標準。火到什么程度，Github上超過26000星。

那么什么到底Redux做了什么？這件事又和Angular2有幾毛錢關系？別著急，我們下面就來講一下。

什么是Redux？

Redux是為了解決應用狀態（State）管理而提出的一種解決方案。那么什么是狀態呢？簡單來說對于應用開發來講，UI上顯示的數據、控件狀態、登陸狀態等等全部可以看作狀態。

我們在開發中經常會碰到，這個界面的按鈕需要在某種情況下變灰；那個界面上需要根據不同情況顯示不同數量的Tab；這個界面的某個值的設定會影響另一個界面的某種展現等等。應該說應用開發中最復雜的部分就在于這些狀態的管理。很多項目隨著需求的迭代，代碼規模逐漸擴大、團隊人員水平參差不齊就會遇到各種狀態管理極其混亂，導致代碼的可維護性和擴展性降低。

那么Redux怎么解決這個問題呢？它提出了幾個概念：Reducer、Action、Store。

Store

可以把Store想象成一個數據庫，就像我們在移動應用開發中使用的SQLite一樣，Store是一個你應用內的數據（狀態）中心。Store在Redux中有一個基本原則：它是一個唯一的、狀態不可修改的樹，狀態的更新只能通過顯性定義的Action發送后觸發。

Store中一般負責：保存應用狀態、提供訪問狀態的方法、派發Action的方法以及對于狀態訂閱者的注冊和取消等。

遵守這個約定的話，任何時間點的Store的快照都可以提供一個完整當時的應用狀態。這在調試應用時會變得非常方便，有沒有想過在調試時可以任意的返回前面的某一時間點？Redux的TimeMachine調試器會帶我們進行這種時光旅行，后面我們會一起體驗！

Reducer

我在有一段時間一直覺得Reducer這個東西不好理解，主要原因有兩個：

其一是這個英語單詞有多個含義，在詞典上給出的最靠前的意思是漸縮管和減壓閥。我之前一直望文生義的覺得這個Reducer應該有減速作用，感覺是不是和Rx的zip有點像（這個理解是錯的，只是當時看到這個詞的感覺）。

其二是我看了Redux的作者的一段視頻，里面他用數組的reduce方法來做類比，而我之前對reduce的理解是reduce就是對數組元素進行累加計算成為一個值。

其實作者也沒有說錯，因為數組的reduce操作就是給出不斷的用序列中的值經過累加器計算得到新的值，這和舊狀態進入reducer經處理返回新狀態是一樣的。只不過打的這個比方我比較無感。

這兩個因素導致我當時沒理解正確reducer的含義，現在我比較喜歡把reducer的英文解釋成是“異形接頭”（見下圖）。Reducer的作用是接收一個狀態和對應的處理（Action），進行處理后返回一個新狀態。

很多網上的文章說可以把Reducer想象成數據庫中的表，也就是Store是數據庫，而一個reducer就是其中一張表。我其實覺得Reducer不太像表，還是覺得這個“異形接頭”的概念比較適合我。

Reducer是一個純javascript函數，接收2個參數：第一個是處理之前的狀態，第二個是一個可能攜帶數據的動作（Action）。就是類似下面給出的接口定義，這個是TypeScript的定義，由于JavaScript中沒有強類型，所以用TypeScript來理解一下。

export interface Reducer<T> {(state: T, action: Action): T; }

那么純函數是意味著什么呢？意味著我們理論上可以把reducer移植到所有支持Redux的框架上，不用做改動。下面我們來看一段簡單的代碼：

export const counter: Reducer<number> = (state = 0, action) => {switch(action.type){case 'INCREMENT':return state + action.payload;case 'DECREMENT':return state - action.payload;default:return state;} };

上面的代碼定義了一個計數器的Reducer，一開始的狀態初始值為0（(state = 0, action) 中的 state=0 給state賦了一個初始狀態值）根據Action類型的不同返回不同的狀態。這段代碼就是非常簡單的javascript，不依賴任何框架，可以在React中使用，也可以在接下來的我們要學習的Angular2中使用。

Action

Store中存儲了我們的應用狀態，Reducer接收之前的狀態并輸出新狀態，但是我們如何讓Reducer和Store之間通信呢？這就是Action的職責所在。在Redux規范中，所有的會引發狀態更新的交互行為都必須通過一個顯性定義的Action來進行。

下面的示意圖描述了如果使用上面代碼的Reducer，顯性定義一個Action {type: 'INCREMENT', payload: 2} 并且 dispatch 這個Action后的流程。

比如說之前的計數器狀態是1，我們派送這個Action后，reducer接收到之前的狀態1作為第一個參數，這個Action作為第二個參數。在Switch分支中走的是INCRMENT這個流程，也就是state+action.payload，輸出的新狀態為3.這個狀態保存到Store中。

值得注意的一點是payload并不是一個必選項，看一下Action的TypeScript定義，注意到 payload?: any 那個 ? 沒有，那個就是說這個值可以沒有。

export interface Action {type: string;payload?: any; }

為什么要在Angular2中使用？

首先，正如C#當初在主流強類型語言中率先引入Lamda之后，現在Java8也引入了這個特性一樣，所有的好的模式、好的特性最終會在各個平臺框架上有體現。Redux本身在React社區中的大量使用本身已經證明這種狀態管理機制是非常健壯的。

再有我們可以來看一下在Angular中現有的狀態管理機制是什么樣子的。目前的管理機制就是…嗯…沒有統一的狀態管理機制。

這種沒有統一管理機制的情況在一個大團隊是很恐怖的事情，狀態管理的代碼質量完全看個人水平，這樣會導致功能越來越多的應用中的狀態幾乎是無法測試的。

還是用代碼來說話吧，下面我們看一下一個不用Redux管理的Angular應用是怎樣的。我們就拿最常見的Todo應用來解析（題外話：這個應用已經變成web框架的標準對標項目了，就像上個10年的PetStore是第一代web框架的對標項目一樣。）

第一種狀態管理：我們在組件中管理。在組件中可以聲明一個數組，這個數組作為todo的內存存儲。每次操作比如新增（addTodo）或切換狀態（toggleTodo）首先調用服務中的方法，然后手動操作數組來更新狀態。

export class TodoComponent implements OnInit {desc: string = '';todos : Todo[] = [];//在組件中建立一個內存TodoList數組constructor(@Inject('todoService') private service,private route: ActivatedRoute,private router: Router) {}ngOnInit() {this.route.params.forEach((params: Params) => {let filter = params['filter'];this.filterTodos(filter);});}addTodo(){this.service.addTodo(this.desc) //通過服務新增數據到服務器數據庫.then(todo => {//更新todos的狀態this.todos.push(todo);//使用了可改變的數組操作方式});}toggleTodo(todo: Todo){const i = this.todos.indexOf(todo);this.service.toggleTodo(todo)//通過服務更新數據到服務器數據庫.then(t => {//更新todos的狀態const i = todos.indexOf(todo);todos[i].completed = todo.completed; //使用了可改變的數組操作方式});}...

第二種方式呢，我們在服務中做類似的事情。在服務中定義一個內存存儲（dataStore），然后同樣是在更新服務器數據后手動更新內存存儲。這個版本當中我們使用了RxJS，但大體邏輯是差不多的。當然使用Rx的好處比較明顯，組件只需訪問todos屬性方法即可，組件內的邏輯會比較簡單。

... export class TodoService {private api_url = 'http://localhost:3000/todos';private headers = new Headers({'Content-Type': 'application/json'});private userId: string;private _todos: BehaviorSubject<Todo[]>; private dataStore: { // 我們自己實現的內存數據存儲todos: Todo[]};constructor(private http: Http, @Inject('auth') private authService) {this.authService.getAuth().filter(auth => auth.user != null).subscribe(auth => this.userId = auth.user.id);this.dataStore = { todos: [] };this._todos = new BehaviorSubject<Todo[]>([]);}get todos(){return this._todos.asObservable();}// POST /todosaddTodo(desc:string){let todoToAdd = {id: UUID.UUID(),desc: desc,completed: false,userId: this.userId};this.http.post(this.api_url, JSON.stringify(todoToAdd), {headers: this.headers}).map(res => res.json() as Todo) //通過服務新增數據到服務器數據庫.subscribe(todo => {//更新內存存儲todos的狀態//使用了不可改變的數組操作方式this.dataStore.todos = [...this.dataStore.todos, todo];//推送給訂閱者新的內存存儲數據this._todos.next(Object.assign({}, this.dataStore).todos);});}toggleTodo(todo: Todo) {const url = `${this.api_url}/${todo.id}`;const i = this.dataStore.todos.indexOf(todo);let updatedTodo = Object.assign({}, todo, {completed: !todo.completed});this.http.patch(url, JSON.stringify({completed: !todo.completed}), {headers: this.headers})//通過服務更新數據到服務器數據庫.subscribe(_ => {//更新內存存儲todos的狀態this.dataStore.todos = [...this.dataStore.todos.slice(0,i),updatedTodo,...this.dataStore.todos.slice(i+1)];//使用了不可改變的數組操作方式//推送給訂閱者新的內存存儲數據this._todos.next(Object.assign({}, this.dataStore).todos);});} ... }

當然還有很多方式，比如服務中維護一部分，組件中維護一部分；再比如說有的同學可能使用localStorage做存儲，每次讀來寫去等等。

不是說這些方式不好（如果可以保持項目組內的規范統一，項目較小的情況下也還可以），而是說代碼編寫的方式太多了，而且狀態分散在各個組件和服務中，沒有統一管理。一個小項目可能還沒有問題，但大項目就會發現內存狀態很難統一維護。

更不用說在Angular2中我們寫了很多組件里的EventEmitter只是為了把某個事件彈射到父組件中而已。而這些在Redux的模式下，都可以很方便的解決，我們同樣可以很自由的在服務或組件中引用store。但不管怎樣編寫，我們遵守的同樣的規則，維護的是應用唯一狀態樹。

Angular 1.x永久的改變了JQuery類型的web開發，使得我們可以像寫手機客戶端App一樣來鞋前端代碼。Redux也一樣改變了狀態管理的寫法，Redux其實不僅僅是一個類庫，更是一種設計模式。而且在Angular2 中由于有RxJS，你會發現我們甚至比在React中使用時更方便更強大。

在Angular 2中使用Redux

ngrx是一套利用RxJS的類庫，其中的 @ngrx/store (https://github.com/ngrx/store) 就是基于Redux規范制定的Angular2框架。接下來我們一起看看如何使用這套框架做一個Todo應用。

對Angular2 不熟悉的童鞋可以去 https://github.com/wpcfan/awesome-tutorials/blob/master/angular2/ng2-tut/README.md 看我的Angular 2: 從0到1系列

簡單內存版

當然第一步是安裝 npm install @ngrx/core @ngrx/store --save。然后需要在你想要使用的Module里面引入store，我推薦在根模塊 AppModule或CoreModule（把只在應用中加載一次的全局性東東單獨放到一個Module中然后在AppModule引入） 引入這個包，因為Store是整個應用的狀態樹。

import { ModuleWithProviders, NgModule, Optional, SkipSelf } from '@angular/core'; import { AuthService } from './auth.service'; import { UserService } from './user.service'; import { AuthGuardService } from './auth-guard.service';import { HttpModule, JsonpModule } from '@angular/http'; import { StoreModule } from '@ngrx/store'; import { todoReducer, todoFilterReducer } from '../reducers/todo.reducer'; import { authReducer } from '../reducers/auth.reducer';@NgModule({imports:[HttpModuleStoreModule.provideStore({ todos: todoReducer, todoFilter: todoFilterReducer})],providers: [AuthService,UserService,AuthGuardService] }) export class CoreModule {constructor (@Optional() @SkipSelf() parentModule: CoreModule) {if (parentModule) {throw new Error('CoreModule is already loaded. Import it in the AppModule only');}} }

我們看到StoreModule提供了一個provideStore方法，在這個方法中我們聲明了一個 { todos: todoReducer, todoFilter: todoFilterReducer }對象，這個就是Store。前面講過Store可以想象成數據庫，Reducer可以想象成表，那么這樣一個對象形式告訴我們數據庫是由那些表構成的（這個地方把Reducer想象成表還是有道理的）.

那么可以看到我們定義了兩個Reducer：todoReducer和todoFilterReducer。在看代碼之前，我們來思考一下這個流程，所謂Reducer其實就是接收兩個參數：之前的狀態和要采取的動作，然后返回新的狀態?？赡軇幼鞲孟胍恍?#xff0c;先看看有什么動作吧：

• 新增一個Todo
• 刪除一個Todo
• 更改Todo的完成狀態
• 全部反轉Todo的完成狀態
• 清除已完成的Todo
• 篩選全部Todo
• 篩選未完成的Todo
• 篩選已完成的Todo

但是仔細分析一下發現后三個動作其實和前面的不太一樣，因為后面的三個都屬于篩選，并未改動數據本身。也不用提交后臺服務，只需要對內存數據做簡單篩選即可。前面幾個都需要不光改變內存數據也需要改變服務器數據。

這里我們先嘗試著寫一下前面五個動作對應的Reducer，按前面定義的就叫todoReducer吧，一開始也不知道怎么寫好，那就先寫個骨架吧：

export const todoReducer = (state = [], {type, payload}) => {switch (type) {default:return state;} }

即使是個骨架，也有很多有意思的點。

第一個參數是state，就像我們在組件或服務中自己維護了一個內存數組一樣，我們的Todo狀態其實也是一個數組，我們還賦了一個空數組的初始值（避免出現undefined錯誤）。

第二個參數是一個有type和payload兩個屬性的對象，其實就是Action。也就是說我們其實可以不用定義Action，直接給出構造的對象形式即可。內部的話其實reducer就是一個大的switch語句，根據不同的Action類型決定返回什么樣的狀態。默認狀態下我們直接將之前狀態返回即可。Reducer就是這么單純的一個函數。

現在我們來考慮其中一個動作，增加一個Todo，我們需要發送一個Action，這個Action的type是 ’ADD_TODO’ ，payload就是新增加的這個Todo。

邏輯其實就是列表數組增加一個元素，用數組的push方法直接做是不是就行了呢？不行，因為Redux的約定是必須返回一個新狀態，而不是更新原來的狀態。而push方法其實是更新原來的數組，而我們需要返回一個新的數組。感謝ES7的Object Spread操作符，它可以讓我們非常方便的返回一個新的數組。

export const todoReducer = (state = [], {type, payload}) => {switch (type) {case 'ADD_TODO':return [...state,action.payload];default:return state;} }

現在我們已經有了一個可以處理 ADD_TODO 類型的Reducer?？赡苡械耐瑢W要問這只是改變了內存的數據，我們怎么處理服務器的數據更改呢？要不要在Reducer中處理？答案是服務器數據處理的邏輯是服務（Service）的職責，Reducer不負責那部分。后面我們會處理服務器的數據更新的。

接下來工作就很簡單了，我們在TodoComponent中去引入Store并且在適當的時候dispatch ‘ADD_TODO’這個Action就OK了。

... export class TodoComponent {...todos : Observable<Todo[]>;constructor(private store$: Store<Todo[]>) {...this.todos = this.store$.select('todos');}addTodo(desc: string) {let todoToAdd = {id: '1',desc: desc,completed: false}this.store$.dispatch({type: 'ADD_TODO', todoToAdd});}... }

利用Angular提供的依賴性注入（DI），我們可以非常方便的在構造函數中注入Store。由于Angular2對于RxJS的內建支持以及 @ngrx/store 本身也是基于RxJS來構造的，我們完全不用Redux的注冊訂閱者等行為，訪問todos這個狀態，只需要寫成 this.store$.select('todos')就可以了。這個store后面有個 $ 符號是表示這是一個流（Stream，只是寫法上的慣例），也就是Observable。然后在addTodo方法中把action發送出去就完事了，當然這個方法是在按Enter鍵時觸發的。

<div><app-todo-headerplaceholder="What do you want"(onEnterUp)="addTodo($event)" ></app-todo-header><app-todo-list[todos]="todos | async"(onToggleAll)="toggleAll()"(onRemoveTodo)="removeTodo($event)"(onToggleTodo)="toggleTodo($event)"></app-todo-list><app-todo-footer[itemCount]="(todos | async)?.length"(onClear)="clearCompleted()"></app-todo-footer> </div>

似乎有點太簡單了吧，但真的是這樣，比在React中使用還要簡便。Angular2中對于Observable類型的變量提供了一個Async Pipe，就是 todos | async ，我們連在OnDestroy中取消訂閱都不用做了。

下面我們把reducer的其他部分補全吧。除了處理todoReducer中其他的swtich分支，我們為其添加了強類型，既然是在Angular2中使用TypeScript開發，我們還是希望享受強類型帶來的各種便利之處。另外總是對于Action的Type定義了一系列常量。

import { Reducer, Action } from '@ngrx/store'; import { Todo } from '../domain/entities'; import { ADD_TODO, REMOVE_TODO, TOGGLE_TODO,TOGGLE_ALL,CLEAR_COMPLETED,FETCH_FROM_API,VisibilityFilters } from '../actions/todo.action';export const todoReducer = (state: Todo[] =[], action: Action) => {switch (action.type) {case ADD_TODO:return [...state,action.payload];case REMOVE_TODO:return state.filter(todo => todo.id !== action.payload.id);case TOGGLE_TODO:return state.map(todo => {if(todo.id !== action.payload.id){return todo;}return Object.assign({}, todo, {completed: !todo.completed});});case TOGGLE_ALL:return state.map(todo => {return Object.assign({}, todo, {completed: !todo.completed});});case CLEAR_COMPLETED:return state.filter(todo => !todo.completed);case FETCH_FROM_API:return [...action.payload];default:return state;} }export const todoFilterReducer = (state = (todo: Todo) => todo, action: Action) => {switch (action.type) {case VisibilityFilters.SHOW_ALL:return todo => todo;case VisibilityFilters.SHOW_ACTIVE:return todo => !todo.completed;case VisibilityFilters.SHOW_COMPLETED:return todo => todo.completed;default:return state;} }

上面的todoReducer看起來倒還是很正常，這個todoFilterReducer卻形跡十分可疑，它的state看上去是個函數。是的，你的判斷是對的，的確是函數。

為什么我們要這么設計呢？原因是這幾個過濾器，其實只是對內存數組進行篩選操作，那么就可以通過 arr.filter(callback[, thisArg]) 來進行篩選。數組的filter方法的含義是對于數組中每一個元素通過callback的測試，然后返回值組成一個新數組。所以這個Reducer中我們的狀態其實是不同條件的測試函數，就是那個callback。

好，我們一起把這個沒有后臺API的版本先完成了吧，要完成的其他部分都很簡單，比如toggle、remove什么的，因為只是調用store的dispatch方法把Action發送出去即可。

... export class TodoComponent {todos : Observable<Todo[]>;constructor(private service: TodoService,private route: ActivatedRoute,private store$: Store<Todo[]>) {const fetchData$ = this.store$.select('todos').startWith([]);const filterData$ = this.store$.select('todoFilter');this.todos = Observable.combineLatest(fetchData$,filterData$,(todos: Todo[], filter: any) => todos.filter(filter))}ngInit(){this.route.params.pluck('filter').subscribe(value => {const filter = value as string;this.store$.dispatch({type: filter});})}addTodo(desc: string) {let todoToAdd = {id: UUID.UUID(),desc: desc,completed: false};this.store$.dispatch({type: ADD_TODO, payload: todoToAdd});}toggleTodo(todo: Todo) {let updatedTodo = Object.assign({}, todo, {completed: !todo.completed});this.store$.dispatch({type: TOGGLE_TODO, payload: updatedTodo});}removeTodo(todo: Todo) {this.store$.dispatch({type: REMOVE_TODO,payload: todo});} toggleAll(){this.store$.dispatch({type: TOGGLE_ALL});}clearCompleted(){this.store$.dispatch({type: CLEAR_COMPLETED});} }

我們一起看看過濾器部分怎么處理我們實現的，我們知道目前有兩個和todo有關的Reducer：todoReducer和todoFilterReducer。這兩個應該是配合來影響狀態的，我們不可以在沒有任何一方的情況下獨立返回正常的狀態。怎么理解呢？打個比方吧，我們添加了幾個Todo之后，這些Todo肯定滿足某個過濾器的條件測試，而不可能存在一個Todo在任何一個過濾器中都不滿足其條件。

那么如何配合處理這兩個狀態流呢（在@ngrx/store中，它們都是流）？重新描述一下對這兩個流的要求，為方便起見，我們叫todos流和filter流。我們想要這樣的一個合并流，這個合并流的數據來自于todos流和filter流。而且合并流的每個數據都來自于一對最新的todos流數據和filter流數據，當然存在一種情況：一個流產生了新數據，但另一個沒有。這種情況下，我們會使用新產生的這個數據和另一個流中之前最新的那個配對產生合并流的數據。

這在Rx世界太簡單了，combineLatest操作符干的就是這樣一件事。于是我們看到下面這段代碼：我們合并了todos流和filter流，而且在以它們各自的最新數據為參數的一個函數產生了新的合并流的數據 todos.filter(filter)。稍微解釋一下，todos流中的數據就是todo數組，我們在todoReducer中就是這樣定義的，而filter流中的數據是一個函數，那么我們其實就是使用從todos流中的最新數組，調用todos.filter方法然后把filter流中的最新的函數當成todos.filter的參數。

const fetchData$ = this.store$.select('todos').startWith([]); const filterData$ = this.store$.select('todoFilter'); this.todos = Observable.combineLatest(fetchData$,filterData$,(todos: Todo[], filter: any) => todos.filter(filter) )

還有一處需要解釋并且優化的代碼位于ngInit中的那段，我們把它分拆出來列在下面。我們在Todo里面實現過濾器時使用的是Angular2的路由參數，也就是 todo/:filter 這種形式（我們定義在 todo-routing.module.ts 中了 ），比如如果過濾器是 ALL，那么這個表現形式就是 todo/ALL。下面代碼中的 this.route.params.pluck('filter') 就是取得這個filter路由參數的值。然后我們dispatch了要進行過濾的action。

ngInit(){this.route.params.pluck('filter').subscribe(value => {const filter = value as string;this.store$.dispatch({type: filter});})}

雖說現在的形式已經可以正常工作了，但總覺得這個路由參數的獲取單獨放在這里有點別扭，因為邏輯上這個路由參數流和filter流是有先后順序的，而且后者依賴前者，但這種邏輯關系沒有體現出來。

嗯，來優化一下，Rx的一個優點就是可以把一系列操作串（chain）起來。從時間序列上看這個路由參數的獲取是先發生的，然后獲取到這個參數filter流才會有作用，那么我們優化的點就在于怎么樣把這個路由參數流和filter流串起來。

const filterData$ = this.route.params.pluck('filter').do(value => {const filter = value as string;this.store$.dispatch({type: filter});}).flatMap(_ => this.store$.select('todoFilter'));

上面的代碼把原來獨立的兩個流串了起來，邏輯關系有兩層：

首先時間順序要保證，也就是說路由參數的先有數據后 this.store$.select('todoFilter') 才可以工作。 do 相當于在語句中間臨時subscribe一下，我們在此時發送了Action。

再有我們并不關心路由參數流的數據，我們只是關心它什么時候有數據，所以我們在 flatMap 語句中把參數寫成了 _。

到這里，我們的內存版redux化的Angular2 Todo應用就搞定了。

時光旅行調試器 — Redux TimeMachine Debugge

在介紹HTTP后臺版本之前，我們要隆重推出大名鼎鼎的Redux時光旅行調試器。首先需要下載Redux DevTools for Chrome，在Chrome商店中搜索 Redux DevTools即可。

安裝好插件之后，我們需要在為 @ngrx/store 安裝一個dev-tools的npm包： npm install @ngrx/store-devtools --save

然后在AppModule或CoreModule的Module元數據中加上 StoreDevtoolsModule.instrumentOnlyWithExtension()

... import { StoreDevtoolsModule } from '@ngrx/store-devtools'; @NgModule({imports:[...StoreModule.provideStore({ todos: todoReducer, todoFilter: todoFilterReducer}),StoreDevtoolsModule.instrumentOnlyWithExtension()],... })

這樣就配置好了，讓我們先看看它長什么樣吧，打開瀏覽器進入todo應用。對了，別忘打開chrome的開發者工具，你應該可以看到Redux那個Tab，切換過去就好。

為什么叫它時光旅行調試器呢？因為傳統的Debugger只能單向的往前走，不能回退。還記得我們有多少時間浪費在不斷重新調試，一步步跟蹤，不斷添加watch的變量嗎？這一切在Redux中都不存在，我們可以時光穿梭到任何一個已發生的步驟。而且我們可以選擇看看如果沒有某個步驟會是什么樣子。

我們來試驗一下，對于顯示的某個todo做切換完成狀態，然后我們會發現右側的Inspector隨即出現了TOGGLE_TODO的Action。你如果點一下這個Action，會發現出現了一個Skip按鈕，點一下這個按鈕吧，剛才那個Item的狀態又恢復成之前的樣子了。其實點任何一個步驟都沒問題。

而且可以隨時試驗手動編輯一個Action，發射出去會是什么樣子。還有很多其他功能，大家自己試驗摸索吧。

帶HTTP后臺版本

在前面鋪墊的基礎上，做這個版本很容易了。我們用json-server可以快速建立一套REST的Web API。json-server只需要我們提供一個json數據樣本就可以完成Web API了，我們的樣本json是這樣的：

{"todos": [{"id": "6e628423-be05-204f-f075-527cc1bb10d8","desc": "have lunch","completed": false},{"id": "40ab7081-cab9-5900-4048-f4ea905afd2f","desc": "take a break","completed": false},{"id": "6ae06293-23d4-c0ca-ee5b-880365dbd48b","desc": "having fun","completed": false},{"id": "e54f5e86-a781-acd5-1d16-8b878c7cba5d","desc": "have a test","completed": true}] }

然后把這個數據文件起個名，比如叫 data.json 放在 src/app 下，使用 json-server ./src/app/data.json 啟動api服務。

現在我們再來梳理一下如果使用后臺版本的邏輯，我們的現在的數據源其實是來自于服務器API的，每次更改Todo后也都要提交到服務器。這個聯動關系比較強，也就是說必須要服務器返回成功數據后才能進行內存狀態的改變。這種情況下我們似乎應該把某些dispatch的動作放到service中。拿addTodo舉個例子，我們post到服務器一個新增todo的請求后在發送了dispatch ADD_TODO的消息，這時內存狀態就會根據這個進行狀態的遷轉。

import { Injectable, Inject } from '@angular/core'; import { Http, Headers } from '@angular/http'; import { UUID } from 'angular2-uuid';import { Observable } from 'rxjs/Observable'; import { Store } from '@ngrx/store'; import { Todo } from '../domain/entities';import {ADD_TODO,TOGGLE_TODO,REMOVE_TODO,TOGGLE_ALL,CLEAR_COMPLETED } from '../actions/todo.action'@Injectable() export class TodoService {private api_url = 'http://localhost:3000/todos';private headers = new Headers({'Content-Type': 'application/json'});private userId: string;constructor(private http: Http, @Inject('auth') private authService,private store$: Store<Todo[]>) {this.authService.getAuth().filter(auth => auth.user != null).subscribe(auth => this.userId = auth.user.id);}// POST /todosaddTodo(desc:string): void{let todoToAdd = {id: UUID.UUID(),desc: desc,completed: false};this.http.post(this.api_url, JSON.stringify(todoToAdd), {headers: this.headers}).map(res => res.json() as Todo).subscribe(todo => {this.store$.dispatch({type: ADD_TODO, payload: todo});});}// PATCH /todos/:id toggleTodo(todo: Todo): void {const url = `${this.api_url}/${todo.id}`;let updatedTodo = Object.assign({}, todo, {completed: !todo.completed});this.http.patch(url, JSON.stringify({completed: !todo.completed}), {headers: this.headers}).mapTo(updatedTodo).subscribe(todo => {this.store$.dispatch({type: TOGGLE_TODO, payload: updatedTodo});});}// DELETE /todos/:idremoveTodo(todo: Todo): void {const url = `${this.api_url}/${todo.id}`;this.http.delete(url, {headers: this.headers}).mapTo(Object.assign({}, todo)).subscribe(todo => {this.store$.dispatch({type: REMOVE_TODO,payload: todo});});}// GET /todosgetTodos(): Observable<Todo[]> {return this.http.get(`${this.api_url}?userId=${this.userId}`).map(res => res.json() as Todo[]);}toggleAll(): void{this.getTodos().flatMap(todos => Observable.from(todos)).flatMap(todo=> { const url = `${this.api_url}/${todo.id}`;let updatedTodo = Object.assign({}, todo, {completed: !todo.completed});return this.http.patch(url, JSON.stringify({completed: !todo.completed}), {headers: this.headers})}).subscribe(()=>{this.store$.dispatch({type: TOGGLE_ALL});})}clearCompleted(): void {this.getTodos().flatMap(todos => Observable.from(todos.filter(t => t.completed))).flatMap(todo=> {const url = `${this.api_url}/${todo.id}`;return this.http.delete(url, {headers: this.headers})}).subscribe(()=>{this.store$.dispatch({type: CLEAR_COMPLETED});});} }

增刪改這些操作應該都沒有問題了，但此時存在一個新問題：內存狀態如何可以通過服務器得到初始值呢？原來的內存版本中，我們初始化就是一個空數組，但現在不一樣了，你可能會有上次已經創建好的todo需要在一開始顯示出來。

如何改變那個初始值呢？但如果換個角度想，現在引入了服務器之后，我們從服務器取數據完全可以定義一個新的Action，比如叫 FETCH_FROM_API 吧。我們現在只需要從服務器取得新數據后發送這個Action，應用狀態就會根據取得的最新服務器數據刷新了。

import { Component, Inject } from '@angular/core'; import { ActivatedRoute } from '@angular/router'; import { TodoService } from './todo.service'; import { Todo } from '../domain/entities'; import { UUID } from 'angular2-uuid'; import { Store } from '@ngrx/store'; import {FETCH_FROM_API } from '../actions/todo.action'import { Observable } from 'rxjs/Observable';@Component({templateUrl: './todo.component.html',styleUrls: ['./todo.component.css'] }) export class TodoComponent {todos : Observable<Todo[]>;constructor(private service: TodoService,private route: ActivatedRoute,private store$: Store<Todo[]>) {const fetchData$ = this.service.getTodos().flatMap(todos => {this.store$.dispatch({type: FETCH_FROM_API, payload: todos});return this.store$.select('todos')}).startWith([]);const filterData$ = this.route.params.pluck('filter').do(value => {const filter = value as string;this.store$.dispatch({type: filter});}).flatMap(_ => this.store$.select('todoFilter'));this.todos = Observable.combineLatest(fetchData$,filterData$,(todos: Todo[], filter: any) => todos.filter(filter))}addTodo(desc: string) {this.service.addTodo(desc);}toggleTodo(todo: Todo) {this.service.toggleTodo(todo);}removeTodo(todo: Todo) {this.service.removeTodo(todo);} toggleAll(){this.service.toggleAll();}clearCompleted(){this.service.clearCompleted();} }

現在服務器版本算是可以工作了，打開瀏覽器試一試吧。現在我們的代碼非常清晰：組件中不處理事務邏輯，只負責調用服務的方法。服務中只負責提交數據到服務器和發送動作。所有的應用狀態都是通過Redux處理的。

一點小思考

雖然服務器版本可以work了，但為什么獲取數據和fitler這段不可以放在服務中呢？為什么要遺留這部分代碼在組件中？這個問題很好，我們一起來試驗一下，實踐是檢驗真理的唯一標準。

把組件構造函數中的代碼移到Service的構造函數中，當然同樣在Service中注入ActiveRoutes。

const fetchData$ = this.getTodos() .do(todos => { this.store$.dispatch({ type: FETCH_FROM_API, payload: todos }) }) .flatMap(this.store$.select('todos')) .startWith([]); const filterData$ = this.route.params.pluck('filter') .do(value => { const filter = value as string; this.store$.dispatch({type: filter}); }) .flatMap(_ => this.store$.select('todoFilter')); this.todos = Observable.combineLatest( fetchData$, filterData$, (todos: Todo[], filter: any) => todos.filter(filter) )

悲催的是，和我們想象的完全不一樣，報錯了。這是由于Service默認情況下是單件形式（Singleton），而ActivatedRoutes并不是，所以注入到service的routes并不是后來激活的那個。當然也有解決辦法，但那個就不是本章的目標。

我們提出這個問題在于告訴大家@ngrx/store的靈活性，它既可以在Service中使用也可以在組件中使用，也可以混合使用，但都不會影響應用狀態的獨立性。在現實的編程環境中，我們經常會遇到自己不可改變的事實，比如已有的代碼實現方式、或者第三方類庫等無法更改的情況，這時候@ngrx/store的靈活性就可以幫助我們在項目中無需做大的更改的情況下進行更清晰的狀態管理了。

我實現的Todo其實是多用戶版本，比這個例子里有多了一些東西。大家可以去
https://github.com/wpcfan/awesome-tutorials/tree/chapter09 查看代碼

Angular2和Rx的相關知識可以看我的Angular 2.0 從0到1系列
第一節：Angular 2.0 從0到1 （一）
第二節：Angular 2.0 從0到1 （二）
第三節：Angular 2.0 從0到1 （三）
第四節：Angular 2.0 從0到1 （四）
第五節：Angular 2.0 從0到1 （五）
第六節：Angular 2.0 從0到1 （六）
第七節：Angular 2.0 從0到1 （七）
第八節：Angular 2.0 從0到1 （八）
番外：Angular 2.0 從0到1 （八）
番外：Angular 2.0 從0到1 Rx—Redux你的Angular 2應用

本文參與了掘金技術征文：https://gold.xitu.io/post/58522dca128fe1006b54da92

?

轉載于:https://www.cnblogs.com/wan9pen9/p/6262495.html

總結

以上是生活随笔為你收集整理的Redux你的Angular 2应用--ngRx使用体验的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。