【全棧React】第18天: Flux 簡介

本文轉載自：衆成翻譯
譯者：iOSDevLog
連接：http://www.zcfy.cc/article/3812
原文：https://www.fullstackreact.com/30-days-of-react/day-18/

處理客戶端應用中的數據是一項複雜的任務。今天咱們正在研究一種處理Facebook提出的複雜數據的方法，稱爲 Flux 體系結構。

隨着應用變得愈來愈複雜, 咱們須要更好的數據處理方法。有了更多的數據, 咱們將有更多的記錄。

咱們的代碼須要使用新功能處理更多的數據和應用狀態。從異步服務器響應到本地生成的、不一樣步的數據, 咱們不只要跟蹤這些數據, 還要將其與視圖保持正常的聯繫。

認識到對數據管理的需求, facebook 團隊發佈了一種處理數據的模式, 稱爲 Flux。

今天, 咱們將看一下Flux體系結構, 它是什麼以及它存在的緣由。

什麼是flux

Flux是一種用於管理數據如何經過React應用流動的模式。正如咱們所看到的, 使用React組件的首選方法是經過從一個父組件向它的子組件傳遞數據。Flux模式使此模型成爲處理數據的默認方法。

在Flux方法中處理數據有三不一樣的角色:

• Dispatcher 派發器

• Stores 儲存

• Views (our components) 視圖層(咱們的組件)

Flux的主要思想是, 有一個單一源 (Stores 儲存), 他們只能經過觸發 actions 更新。這些操做負責調用派發器, Stores能夠 訂閱 更改並相應地更新本身的數據。

When a dispatch has been triggered, and the store updates, it will emit a change event which the views can rerender accordingly.當發送已觸發, 而且存儲更新時, 它將發出一個更改事件, 視圖能夠據此 從新渲染。

這彷佛不必這麼複雜, 但結構使它難以置信地容易推理, 咱們的數據來自哪裏, 致使它的變化, 如何改變, 讓咱們跟蹤特定的用戶流, 等等。

Flux 背後的關鍵理念是:

數據流向一個方向, 並徹底保存在Stores中。

實現

雖然咱們能夠建立咱們本身的flux實現, 許多已經建立了一些夢幻般的庫, 咱們能夠挑選。

• Facebook's flux

• alt

• nuclear-js

• Fluxible

• reflux

• Fluxxor

• flux-react

• 更多... 許多許多許多

插件

咱們深刻討論這個材料關於Flux, 使用庫, 甚至實現咱們本身的版本的Flux, 最適合咱們。
查看 fullstackreact.com

它多是至關激烈的嘗試爲咱們的應用選擇 正確 選項。每一個人由於不一樣的緣由都有本身的特色, 是偉大的。然而, 在很大程度上, React社區已經集中在使用另外一種稱爲Redux的flux工具。

Redux

Redux是一個小的庫, 它的設計靈感來自flux模式, 但自己不是一個純粹的flux實現。它提供了相同的通常原則, 圍繞如何更新咱們的應用中的數據, 但以略微不一樣的方式。

與Flux不一樣, Redux不使用派發器, 而是使用純函數來定義數據變異函數。它仍然使用Store（儲存）和Action（動做）, 能夠直接地被栓到React組件。

3 主要原則的Redux咱們將牢記在咱們的應用中實現Redux是:

• 使用純函數進行更新 (in reducers 在歸約器中)

• state 是隻讀屬性

• state是惟一的來源 (一個Redux的應用只有一個Stores 儲存 )

Redux和Flux的一個大的區別是中間件的概念。Redux增長了中間件的想法, 咱們可使用它來操做咱們接收到的操做, 不管是進入仍是從咱們的應用中。幾天後咱們再詳細討論。

在任何狀況下, 這是不少介紹的flux模式。明天, 咱們將實際開始移動咱們的數據使用Redux。