這篇“在React中怎么處理數(shù)據(jù)流”文章的知識點大部分人都不太理解，所以小編給大家總結(jié)了以下內(nèi)容，內(nèi)容詳細(xì)，步驟清晰，具有一定的借鑒價值，希望大家閱讀完這篇文章能有所收獲，下面我們一起來看看這篇“在React中怎么處理數(shù)據(jù)流”文章吧。

創(chuàng)新互聯(lián)從2013年成立，先為大武口等服務(wù)建站，大武口等地企業(yè)，進(jìn)行企業(yè)商務(wù)咨詢服務(wù)。為大武口企業(yè)網(wǎng)站制作PC+手機(jī)+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問題。

背景

相信大家在項目開發(fā)中，在頁面較復(fù)雜的情況下，往往會遇到一個問題，就是在頁面組件之間通信會非常困難。

比如說一個商品列表和一個已添加商品列表：

假如這兩個列表是獨(dú)立的兩個組件，它們會共享一個數(shù)據(jù) “被選中的商品”，在商品列表選中一個商品，會影響已添加商品列表，在已添加列表中刪除一個商品，同樣會影響商品列表的選中狀態(tài)。

它們兩個是兄弟組件，在沒有數(shù)據(jù)流框架的幫助下，在組件內(nèi)數(shù)據(jù)有變化的時候，只能通過父組件傳輸數(shù)據(jù)，往往會有 onSelectedDataChange 這種函數(shù)出現(xiàn)，在這種情況下，還尚且能忍受，如果組件嵌套較深的話，那痛苦可以想象一下，所以才有解決數(shù)據(jù)流的各種框架的出現(xiàn)。

本質(zhì)分析

我們知道 React 是 MVC 里的 V，并且是數(shù)據(jù)驅(qū)動視圖的，簡單來說，就是數(shù)據(jù) => 視圖，視圖是基于數(shù)據(jù)的渲染結(jié)果：

V = f(M)

數(shù)據(jù)有更新的時候，在進(jìn)入渲染之前，會先生成 Virtual DOM，前后進(jìn)行對比，有變化才進(jìn)行真正的渲染。

V + ΔV = f(M + ΔM)

數(shù)據(jù)驅(qū)動視圖變化有兩種方式，一種是 setState，改變頁面的 state，一種是觸發(fā) props 的變化。

我們知道數(shù)據(jù)是不會自己改變，那么肯定是有“外力”去推動，往往是遠(yuǎn)程請求數(shù)據(jù)回來或者是 UI 上的交互行為，我們統(tǒng)稱這些行為叫 action：

ΔM = perform(action)

每一個 action 都會去改變數(shù)據(jù)，那么視圖得到的數(shù)據(jù)（state）就是所有 action 疊加起來的變更，

state = actions.reduce(reducer, initState)

所以真實的場景會出現(xiàn)如下或更復(fù)雜的情況：

問題就出在，更新數(shù)據(jù)比較麻煩，混亂，每次要更新數(shù)據(jù)，都要一層層傳遞，在頁面交互復(fù)雜的情況下，無法對數(shù)據(jù)進(jìn)行管控。

有沒有一種方式，有個集中的地方去管理數(shù)據(jù)，集中處理數(shù)據(jù)的接收，修改和分發(fā)？答案顯然是有的，數(shù)據(jù)流框架就是做這個事情，熟悉 Redux 的話，就知道其實上面講的就是 Redux 的核心理念，它和 React 的數(shù)據(jù)驅(qū)動原理是相匹配的。

數(shù)據(jù)流框架

Redux

數(shù)據(jù)流框架目前占主要地位的還是 Redux，它提供一個全局 Store 處理應(yīng)用數(shù)據(jù)的接收，修改和分發(fā)。

它的原理比較簡單，View 里面有任何交互行為需要改變數(shù)據(jù)，首先要發(fā)一個 action，這個 action 被 Store 接收并交給對應(yīng)的 reducer 處理，處理完后把更新后的數(shù)據(jù)傳遞給 View。Redux 不依賴于任何框架，它只是定義一種方式控制數(shù)據(jù)的流轉(zhuǎn)，可以應(yīng)用于任何場景。

雖然定義了一套數(shù)據(jù)流轉(zhuǎn)的方式，但真正使用上會有不少問題，我個人總結(jié)主要是兩個問題：

定義過于繁瑣，文件多，容易造成思維跳躍。

異步流的處理沒有優(yōu)雅的方案。

我們來看看寫一個數(shù)據(jù)請求的例子，這是非常典型的案例：

actions.js

export const FETCH_DATA_START = 'FETCH_DATA_START';

export const FETCH_DATA_SUCCESS = 'FETCH_DATA_SUCCESS';

export const FETCH_DATA_ERROR = 'FETCH_DATA_ERROR';

export function fetchData() {

  return dispatch => {

    dispatch(fetchDataStart());

    axios.get('xxx').then((data) => {

      dispatch(fetchDataSuccess(data));

    }).catch((error) => {

      dispatch(fetchDataError(error));

    });

  };

}

export function fetchDataStart() {

  return {

    type: FETCH_DATA_START,

  }

}

...FETCH_DATA_SUCCESS

...FETCH_DATA_ERROR

reducer.js

import { FETCH_DATA_START, FETCH_DATA_SUCCESS, FETCH_DATA_ERROR  } from 'actions.js';

export default (state = { data: null }, action) => {

  switch (action.type) {

    case FETCH_DATA_START:

      ...

    case FETCH_DATA_SUCCESS:

      ...

    case FETCH_DATA_ERROR:

      ...

    default: 

      return state

  }

}

view.js

import { createStore, applyMiddleware } from 'redux';

import thunk from 'redux-thunk';

import reducer from 'reducer.js';

import { fetchData } from 'actions.js';

const store = createStore(reducer, applyMiddleware(thunk));

store.dispatch(fetchData());

第一個問題，發(fā)一個請求，因為需要托管請求的所有狀態(tài)，所以需要定義很多的 action，這時很容易會繞暈，就算有人嘗試把這些狀態(tài)再封裝抽象，也會充斥著一堆模板代碼。有人會挑戰(zhàn)說，雖然一開始是比較麻煩，繁瑣，但對項目可維護(hù)性，擴(kuò)展性都比較友好，我不太認(rèn)同這樣的說法，目前還算簡單，真正業(yè)務(wù)邏輯復(fù)雜的情況下，會顯得更惡心，效率低且閱讀體驗差，相信大家也寫過或看過這樣的代碼，后面自己看回來，需要在 actions 文件搜索一下 action 的名稱，reducer 文件查詢一下，繞一圈才慢慢看懂。

第二個問題，按照官方推薦使用 redux-thunk 實現(xiàn)異步 action 的方法，只要在 action 里返回一個函數(shù)即可，這對有強(qiáng)迫癥的人來說，簡直受不了，actions 文件顯得它很不純，本來它只是來定義 action，卻竟然要夾雜著數(shù)據(jù)請求，甚至 UI 上的交互。

以上就是關(guān)于“在React中怎么處理數(shù)據(jù)流”這篇文章的內(nèi)容，相信大家都有了一定的了解，希望小編分享的內(nèi)容對大家有幫助，若想了解更多相關(guān)的知識內(nèi)容，請關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。