第一節：初識Angular-CLI
第二節：登入元件的構建
第三節：建立一個待辦事項應用
第四節：進化！模組化你的應用
第五節：多使用者版本的待辦事項應用
第六節：使用第三方樣式庫及模組優化用
第七節：給元件帶來活力
Rx--隱藏在Angular 2.x中利劍
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 /todos
addTodo(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 (github.com/ngrx/store) 就是基於Redux規範制定的Angular2框架。接下來我們一起看看如何使用這套框架做一個Todo應用。
對Angular2 不熟悉的童鞋可以去 github.com/wpcfan/awes… 看我的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:[
HttpModule
StoreModule.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其實就是接收兩個引數：之前的狀態和要採取的動作，然後返回新的狀態。可能動作更好想一些，先看看有什麼動作吧：
- 新增一個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。可能有的同學要問這只是改變了記憶體的資料，我們怎麼處理伺服器的資料更改呢？要不要在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-header
placeholder="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 /todos
addTodo(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/:id
removeTodo(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 /todos
getTodos(): 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其實是多使用者版本，比這個例子裡有多了一些東西。大家可以去
github.com/wpcfan/awes… 檢視程式碼
紙書出版了，比網上內容豐富充實了，歡迎大家訂購！
京東連結：item.m.jd.com/product/120…
本文參與了掘金技術徵文：gold.xitu.io/post/58522d…