我對 React Flux 架構的理解

hankkin 發布于2019-08-22 11:59 / 663人閱讀

摘要：當響應時，通過已注冊的回調函數，將提供的數據負載發送給應用中的所有。對外只暴露，不允許提供禁止在任何地方直接操作。是單例作為中的事件分發中心，同時還要管理所有中的事件。

React Flux架構簡介

個人現階段對Flux架構的理解，求拍磚求star!
原文鏈接：https://github.com/kuitos/kuitos.github.io/issues/27

React 簡介請戳這里

Flux是什么

Flux是Facebook用來構建客戶端web應用的應用架構。它利用單向數據流的方式來組合react中的視圖組件。它更像一個模式而不是一個正式的框架，開發者不需要太多的新代碼就可以快速的上手Flux。

Flux的核心部分

1. dispatcher

事件調度中心，flux模型的中心樞紐，管理著Flux應用中的所有數據流。它本質上是Store的回調注冊。每個Store注冊它自己并提供一個回調函數。當Dispatcher響應Action時，通過已注冊的回調函數，將Action提供的數據負載發送給應用中的所有Store。應用層級單例！！

2. store

負責封裝應用的業務邏輯跟數據的交互。

Store中包含應用所有的數據

Store是應用中唯一的數據發生變更的地方

Store中沒有賦值接口---所有數據變更都是由dispatcher發送到store，新的數據隨著Store觸發的change事件傳回view。Store對外只暴露getter，不允許提供setter！！禁止在任何地方直接操作Store。

3. view

controller-view 可以理解成MVC模型中的controller，它一般由應用的頂層容器充當，負責從store中獲取數據并將數據傳遞到子組件中。簡單的應用一般只有一個controller-view，復雜應用中也可以有多個。controller-view是應用中唯一可以操作state的地方(setState())

view(UI組件) ui-component 職責單一只允許調用action觸發事件，數據從由上層容器通過屬性傳遞過來。

4. 其他

action creators 作為dispatcher的輔助函數，通常可以認為是Flux中的第四部分。ActionCreators是相對獨立的，它作為語法上的輔助函數以action的形式使得dispatcher傳遞數據更為便利。

How Flux(Unidirectional Data Flow) Works

view --> actionCreators

// Nav.jsx
export default class Nav extends React.Component {

  _handleClick(nav) {
    NavActionCreators.clickNav(nav);
  }

  render() {

    let itemList = this.props.list.map((nav, index) => {
      return (
        
          {nav.text}
        
      );
    });

    return (
      
        
          {itemList}
        
      
    );
  }
}

action dispatch

// NavActionCreators.js
export default {

  clickNav(nav){

    AppDispatcher.dispatch(
      {
        type: ActionTypes.CLICK_NAV,
        nav
      }
    );
  }
};

dispatcher --> store callback

AppDispatcher.register(action => {

  switch (action.type) {

    // nav點擊
    case ActionTypes.CLICK_NAV:

      IndexWebAPIUtils.getGiftList(_currentUserInfo.userId, action.nav.id)
        .then(function (giftList) {

          _currentGiftList = giftList;
          IndexStore.emitChange();
        });

      break;

    // no default
  }
});

store emitChange --> controller view --> setState

export default class Index extends React.Component {

  constructor(props) {
    super(props);
    let currentUser = UserStore.getCurrentUser();
    this.state = IndexStore.getAll();
  }

  componentDidMount() {
    IndexStore.addChangeListener(this._onChange.bind(this));
  }

  componentWillUnmount() {
    IndexStore.removeChangeListener(this._onChange.bind(this))
  }

  _onChange() {
    this.setState(IndexStore.getAll());
  }

  render() {

    let state = this.state;

    return (
      
        ...
        
        ...
      
    );
  }

}

Flux vs MVVM

MVVM

1. 簡單的MVVM

2. 復雜的MVC

Flux 1. 復雜的Flux

Flux的優勢 1. 數據狀態變得穩定同時行為可預測

因為angular雙向綁定的原因，我們永遠無法知道數據在哪一刻處于穩定狀態，所以我們經常會在angular中看到通過setTimeout的方式處理一些問題(其實有更優雅的解決方案，不在本次討論之內)。同時由于雙向綁定的原因，行為的流向我們也很難預測，當視圖的model變多的時候，如果再加上一堆子視圖依賴這些model，問題發生時定位簡直是噩夢啊(這也是angular的錯誤信息那么不友好的原因，因為框架開發者也無法確定當前行為是誰觸發的啊，綁定的人太多了...)。但是這里還是要強調一點就是，并不是說雙向綁定就一定會導致不穩定的數據狀態，在angular中我們通過一些手段依然可以使得數據變得穩定，只是雙向綁定(mvvm)相對于flux更容易引發數據不穩定的問題。

2. 所有的數據變更都發生在store里

flux里view是不允許直接修改store的，view能做的只是觸發action，然后action通過dispatcher調度最后才會流到store。所有數據的更改都發生在store組件內部，store對外只提供get接口，set行為都發生在內部。store里包含所有相關的數據及業務邏輯。所有store相關數據處理邏輯都集中在一起，避免業務邏輯分散降低維護成本。

3. 數據的渲染是自上而下的

view所有的數據來源只應該是從屬性中傳遞過來的，view的所有表現由上層控制視圖(controller-view)的狀態決定。我們可以把controller-view理解為容器組件，這個容器組件中包含若干細小的子組件，容器組件不同的狀態對應不同的數據，子組件不能有自己的狀態。也就是，數據由store傳遞到controller-view中之后，controller-view通過setState將數據通過屬性的方式自上而下傳遞給各個子view。

4. view層變得很薄，真正的組件化

由于2、3兩條原因，view自身需要做的事情就變得很少了。業務邏輯被store做了，狀態變更被controller-view做了，view自己需要做的只是根據交互觸發不同的action，僅此而已。這樣帶來的好處就是，整個view層變得很薄很純粹，完全的只關注ui層的交互，各個view組件之前完全是松耦合的，大大提高了view組件的復用性。

5. dispatcher是單例的

對單個應用而言dispatcher是單例的，最主要的是dispatcher是數據的分發中心，所有的數據都需要流經dispatcher，dispatcher管理不同action于store之間的關系。因為所有數據都必須在dispatcher這里留下一筆，基于此我們可以做很多有趣的事情，各種debug工具、動作回滾、日志記錄甚至權限攔截之類的都是可以的。

Flux的困境 1. 過多的樣板代碼

flux只是一個架構模式，并不是一個已實現好的框架，所以基于這個模式我們需要寫很多樣板代碼，代碼量duang的一下子上來了。。不過好在目前已經有很多好用的基于flux的第三方實現，目前最火的屬redux。

2. dispatcher是單例

dispatcher作為flux中的事件分發中心，同時還要管理所有store中的事件。當應用中事件一多起來事件時序的管理變得復雜難以維護，沒有一個統一的地方能清晰的表達出dispatcher管理了哪些store。

3. 異步處理到底寫在哪里

按flux流程，action中處理：依賴該action的組件被迫耦合進業務邏輯

按store職責在store中處理：store狀態變得不穩定，dispatcher的waitFor失效

4. 至今還沒有官方實現 寫在最后

前端摩爾定律：前端每18個月難度增加一倍

沒有銀彈

GPU云服務器云服務器 flux架構簡單理解超融合架構 Flux flux框架

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/92346.html

React.js 最佳實踐（2016）_鏈接修正版

摘要：譯者按最近依舊如火如荼相信大家都躍躍欲試我們團隊也開始在領域有所嘗試年應該是逐漸走向成熟的一年讓我們一起來看看國外的開發者們都總結了哪些最佳實踐年在全世界都有很多關于新的更新和開發者大會的討論關于去年的重要事件請參考那么年最有趣的問題來了我譯者按：最近React(web/native)依舊如火如荼,相信大家都躍躍欲試,我們團隊也開始在React領域有所嘗試. 2016年應該是Reac...

syoya 2019-08-19 17:57 評論0 收藏0
關于Flux,Vuex,Redux的思考

摘要：關于的思考是一種前端狀態管理架構思想，專門解決軟件的結構問題。他們給出了一些庫用于實現的思想，并在的基礎上做了一些改進。在這些框架里，當前最熱門的莫過于和了。關于Flux,Vuex,Redux的思考 Flux是一種前端狀態管理架構思想，專門解決軟件的結構問題。基于Flux的設計思想，出現了一批前端狀態管理框架。他們給出了一些庫用于實現Flux的思想，并在Flux的基礎上做了一些改進。...

jsbintask 2019-08-22 10:48 評論0 收藏0
Redux概念之一: Redux簡介

摘要：應用這說明并不是單指設計給用的，它是獨立的一個函數庫，可通用于各種應用。在數據流的最后，要觸發最上層組件的，然后進行整體的重新渲染工作。單純在的對象上是沒有辦法使用，要靠額外的函數庫才能這樣作，這是一定要使用類似像這種函數庫的主要原因。 Redux的官網中用一句話來說明Redux是什么: Redux是針對JavaScript應用的可預測狀態容器這句話雖然簡短，其實是有幾個涵義的: ...

cjie 2019-08-20 13:59 評論0 收藏0
React系列之 Flux架構模式

摘要：原文地址由于只涉及層的處理，所以構建大型應用應該搭配一個框架模式才能使后期維護成本相對較小正是官方給出的應用架構，他推崇一種單向的數據流動模式，看下圖感受下整個流程是用戶與層交互，觸發使用進行分發觸發回調進行更新更新觸發層事件層收到信號進原文地址：https://gmiam.com/post/react-... 由于 React 只涉及 UI 層的處理，所以構建大型應用應該搭配一個框...

whjin 2019-08-20 11:21 評論0 收藏0
我的Android重構之旅：架構篇

摘要：是的架構的實現。是在年提出的一種前端架構，主要用來處理復雜的邏輯的一致性問題當時是為了解決頁面的消息通知問題。去年10月底來到了新公司，剛開始接手 Android 項目時，發現該項目真的是一團遭，項目開發上沒有任何架構可言，開發人員連簡單的 MVC、MVP 都不了解，Activity 及其臃腫，業務邊界也不明確，因此我決定重新分析一下當前主流的幾種開發架構，選出適合當前項目的架構形式...

mylxsw 2019-06-24 18:03 評論0 收藏0