Redux你的Angular 2應用--ngRx使用體驗 | 掘金技術徵文

時間  2019-11-07
標籤 redux angular 應用 ngrx 使用 體驗 技術 徵文 欄目 AngularJS 简体版
原文   原文鏈接

第一節：初識Angular-CLI
第二節：登陸組件的構建
第三節：創建一個待辦事項應用
第四節：進化！模塊化你的應用
第五節：多用戶版本的待辦事項應用
第六節：使用第三方樣式庫及模塊優化用
第七節：給組件帶來活力
Rx--隱藏在Angular 2.x中利劍
Redux你的Angular 2應用
第八節：查缺補漏大合集(上)
第九節：查缺補漏大合集(下)javascript

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

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

Redux的Github項目頁面，超過26000星

那麼什麼到底Redux作了什麼？這件事又和Angular2有幾毛錢關係？彆着急，咱們下面就來說一下。前端

什麼是Redux？

Redux是爲了解決應用狀態（State）管理而提出的一種解決方案。那麼什麼是狀態呢？簡單來講對於應用開發來說，UI上顯示的數據、控件狀態、登錄狀態等等所有能夠看做狀態。java

咱們在開發中常常會碰到，這個界面的按鈕須要在某種狀況下變灰；那個界面上須要根據不一樣狀況顯示不一樣數量的Tab；這個界面的某個值的設定會影響另外一個界面的某種展示等等。應該說應用開發中最複雜的部分就在於這些狀態的管理。不少項目隨着需求的迭代，代碼規模逐漸擴大、團隊人員水平良莠不齊就會遇到各類狀態管理極其混亂，致使代碼的可維護性和擴展性下降。git

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

Store

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

Store中通常負責：保存應用狀態、提供訪問狀態的方法、派發Action的方法以及對於狀態訂閱者的註冊和取消等。chrome

遵照這個約定的話，任什麼時候間點的Store的快照均可以提供一個完整當時的應用狀態。這在調試應用時會變得很是方便，有沒有想過在調試時能夠任意的返回前面的某一時間點？Redux的TimeMachine調試器會帶咱們進行這種時光旅行，後面咱們會一塊兒體驗！數據庫

Reducer

我在有一段時間一直以爲Reducer這個東西很差理解，主要緣由有兩個：

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

其二是我看了Redux的做者的一段視頻，裏面他用數組的reduce方法來作類比，而我以前對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後的流程。

顯性定義的Action觸發Reducer產生新的狀態

好比說以前的計數器狀態是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中現有的狀態管理機制是什麼樣子的。目前的管理機制就是...嗯...沒有統一的狀態管理機制。

遍地開花的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應用。

打造一個有Http後臺的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便可。

image_1b4oekl1o18829t616cv1jd7u3jm.png-232.7kB

安裝好插件以後，咱們須要在爲 @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，切換過去就好。

右側的就是Redux DevTools

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

咱們來試驗一下，對於顯示的某個todo作切換完成狀態，而後咱們會發現右側的Inspector隨即出現了TOGGLE_TODO的Action。你若是點一下這個Action，會發現出現了一個Skip按鈕，點一下這個按鈕吧，剛纔那個Item的狀態又恢復成以前的樣子了。其實點任何一個步驟都沒問題。

點擊某個Action能夠體驗時光旅行

並且能夠隨時試驗手動編輯一個Action，發射出去會是什麼樣子。還有不少其餘功能，你們本身試驗摸索吧。

在調試器中能夠隨時創建一個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的靈活性就能夠幫助咱們在項目中無需作大的更改的狀況下進行更清晰的狀態管理了。

Store便可以在Service中使用也能夠在Component中使用

我實現的Todo實際上是多用戶版本，比這個例子裏有多了一些東西。你們能夠去
github.com/wpcfan/awes… 查看代碼

紙書出版了，比網上內容豐富充實了，歡迎你們訂購！
京東連接：item.m.jd.com/product/120…

Angular從零到一

本文參與了掘金技術徵文：gold.xitu.io/post/58522d…

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程