1. 什么是數(shù)據(jù)流

什么是流?

在數(shù)學(xué)中，一個(gè)流用數(shù)學(xué)方式形式化了“取決于時(shí)間的變化”的一般想法。暫且定義流是響應(yīng)時(shí)間變化的一個(gè)集合體。

什么是數(shù)據(jù)流

依據(jù)之前的定義，數(shù)據(jù)流即隨時(shí)間變化的一個(gè)數(shù)據(jù)集合。

前端針對(duì)于現(xiàn)狀mvvm模式下，數(shù)據(jù)即頁面，在多數(shù)情況下，數(shù)據(jù)不變頁面不變。那么我們轉(zhuǎn)換一下，數(shù)據(jù)==>頁面，數(shù)據(jù)流是否可以等價(jià)為一個(gè)頁面的變化集合。這個(gè)是什么，就是我們的業(yè)務(wù)邏輯。

當(dāng)然，前面的假設(shè)，是經(jīng)過很多轉(zhuǎn)化，其實(shí)有很多漏洞和錯(cuò)誤。但是可以作為一個(gè)簡單的參考。

這個(gè)不是數(shù)據(jù)流的定義，只是作為一個(gè)引子思考。

2. 現(xiàn)行前端數(shù)據(jù)管理模式

現(xiàn)行三大數(shù)據(jù)管理方式

• 函數(shù)式、不可變、模式化。典型實(shí)現(xiàn)：Redux。
• 響應(yīng)式、依賴追蹤。典型實(shí)現(xiàn)：Mobx。
• 響應(yīng)式，以流的形式實(shí)現(xiàn)。Rxjs、xstream。

Redux模式(reduck)

redux模式常規(guī)用法是作為整個(gè)應(yīng)用全局狀態(tài)管理使用。這只是作為一個(gè)提高跨組件通信的能力的工具。redux的思想是作為獨(dú)立于組件的一個(gè)數(shù)據(jù)倉庫，對(duì)數(shù)據(jù)進(jìn)行保護(hù)，保障數(shù)據(jù)穩(wěn)定可靠。

可以簡單理解redux是一個(gè)帶保護(hù)的全局使用的Context(useContext)。

針對(duì)于原生的提供了數(shù)據(jù)保護(hù)(dispatch+reducer)，對(duì)于更改只允許使用dispatch進(jìn)行更改。能夠保障可回溯性，數(shù)據(jù)來源清晰，能夠十分良好的隔絕副作用。

使用方面：

• 優(yōu)點(diǎn)：數(shù)據(jù)隔離，數(shù)據(jù)變化可溯源。
• 缺點(diǎn)：多redux直接完全隔離，小型化困難，action方法容易膨脹。
• 業(yè)務(wù)方面使用：對(duì)于大型項(xiàng)目拆分設(shè)計(jì)概念不足，store數(shù)據(jù)個(gè)人管控不友好，容易造成理解困難邏輯修改困難。

Mobx模式

mobx引入了全新的思想，將數(shù)據(jù)作為一個(gè)源頭，擁有當(dāng)數(shù)據(jù)變化時(shí)，通過計(jì)算狀態(tài)，頁面進(jìn)行變化，并且根據(jù)observable，自動(dòng)根據(jù)依賴執(zhí)行更新。雖然有了action，但還是沒有強(qiáng)制分離副作用。

mobx就好像將數(shù)據(jù)和組件進(jìn)行綁定，形成依賴關(guān)系，自動(dòng)訂閱和自動(dòng)發(fā)布，狀態(tài)變更組件就變更。將邏輯和視圖直接綁定在一起，這本應(yīng)該是十分高效的情況，但是因?yàn)樯钊肓私M件，副作用的處理還是不夠清晰，對(duì)于個(gè)人把控還是不夠友好。

流模式(rxjs)

rxjs和mobx有些相似。rxjs將所有的數(shù)據(jù)都可以隨意的拆散和組合成一個(gè)新的節(jié)點(diǎn)，可以簡單理解為將redux的state進(jìn)行了打散成多個(gè)數(shù)據(jù)節(jié)點(diǎn)，每一個(gè)任意節(jié)點(diǎn)都可以進(jìn)行類似computed的計(jì)算生成新的節(jié)點(diǎn)。

流模式相較于redux模式?jīng)]有action的規(guī)范，卻定義了更改的節(jié)點(diǎn)范圍，只能更改定義的入口節(jié)點(diǎn)(一條流的起始節(jié)點(diǎn))。rxjs沒有mobx從數(shù)據(jù)變化到頁面變化這個(gè)功能，可以使用useState和useEffect實(shí)現(xiàn)或者現(xiàn)成的三方庫rxjs-hooks。

rxjs的優(yōu)勢(shì)是，抽離所有數(shù)據(jù)源之后，剩余全部都是邏輯問題，副作用在抽離數(shù)據(jù)源的時(shí)候就已經(jīng)剝離干凈了(因?yàn)橥獠扛弊饔脭?shù)據(jù)也可以抽離成rxjs的節(jié)點(diǎn))，剩下就通過api和純函數(shù)來編寫具體的邏輯了。

又因?yàn)榇罅康腶pi，拆解observable節(jié)點(diǎn)的成本極低，所以邏輯拆分十分容易，可讀性十分高。

rxjs有推和拉的概念，在正常邏輯十分流暢的情況下，程序的代碼應(yīng)該是每個(gè)節(jié)點(diǎn)轉(zhuǎn)變都會(huì)推動(dòng)下一個(gè)節(jié)點(diǎn)的執(zhí)行。在rxjs中將數(shù)據(jù)流進(jìn)行串流好后，組件只要對(duì)于頭部節(jié)點(diǎn)進(jìn)行讀寫數(shù)據(jù)，對(duì)于尾部節(jié)點(diǎn)直接讀取數(shù)據(jù)就可以，大部分邏輯全部被抽離出了組件。

使用方面：

• 優(yōu)點(diǎn)：邏輯拆分簡便，純函數(shù)式編程。
• 缺點(diǎn)：數(shù)據(jù)拆分復(fù)雜，重設(shè)計(jì)，api學(xué)習(xí)和理解成本高。

理想情況下，頁面就是一個(gè)個(gè)無狀態(tài)組件，行為改變數(shù)據(jù)。數(shù)據(jù)變化又觸發(fā)邏輯變更，邏輯變更數(shù)據(jù)。數(shù)據(jù)又回流到頁面，這是一個(gè)整體的閉環(huán)，以數(shù)據(jù)為核心，完美的做到數(shù)據(jù)驅(qū)動(dòng)頁面。

新星 Recoil

recoil是facebook官方推薦的一個(gè)狀態(tài)管理庫，作為一個(gè)“新成員”，recoil相比于之前的三種狀態(tài)管理方式，做了很多取舍。它有節(jié)點(diǎn)的概念，有atom(原子數(shù)據(jù))和selector(派生數(shù)據(jù))但是不和mobx一樣，recoil是基于Immutable(不變)模式。

recoil的基礎(chǔ)思想是atom數(shù)據(jù)之間沒有關(guān)聯(lián)，產(chǎn)生的關(guān)聯(lián)數(shù)據(jù)全部由selector來產(chǎn)生，atom的變動(dòng)，相關(guān)的selector隨之變動(dòng)，這個(gè)和響應(yīng)式流的思想一致的。

recoil的優(yōu)勢(shì)，貼合react，可以將recoil的實(shí)現(xiàn)當(dāng)作通過useMemo包裝的context，api使用可以滿足只讀，只寫進(jìn)行拆分，可以十分貼合最優(yōu)渲染，降低無用的渲染。

上述前三種數(shù)據(jù)流沒有什么優(yōu)劣好壞之分，只是在不同場(chǎng)景中使用各有各的優(yōu)勢(shì)而已。

3. 理想中的源數(shù)據(jù)編程

數(shù)據(jù)與數(shù)據(jù)之間的關(guān)系

數(shù)據(jù)不是憑空產(chǎn)生的數(shù)據(jù)，數(shù)據(jù)可能又會(huì)產(chǎn)生新的數(shù)據(jù)。

數(shù)據(jù)之間推行的是最小可用原則，分而治之，這才更利于我們開發(fā)和維護(hù)。

個(gè)人把產(chǎn)生數(shù)據(jù)的起始數(shù)據(jù)定義為源數(shù)據(jù)。有些數(shù)據(jù)可以互相轉(zhuǎn)換，那如何定義源數(shù)據(jù)???

定義源數(shù)據(jù)

從組件(頁面)視角看一下數(shù)據(jù)。

• 面向接口編程

大部分情況下前端和后端之間的數(shù)據(jù)交互就只有接口這一種。又因?yàn)檎鎸?shí)的所有數(shù)據(jù)都是從服務(wù)端獲取的數(shù)據(jù)，所以下意識(shí)的以服務(wù)端接口為數(shù)據(jù)起始。數(shù)據(jù)處理的鏈路較長，范圍變大對(duì)于個(gè)人的理解要求是十分高的，個(gè)人認(rèn)為這對(duì)于一個(gè)大型應(yīng)用是不健康的。

• 面向數(shù)據(jù)編程

分離接口請(qǐng)求，只關(guān)心組件狀態(tài)，對(duì)于組件方面，任何數(shù)據(jù)不將其做區(qū)分，數(shù)據(jù)來就渲染。

個(gè)人將用戶可交互的數(shù)據(jù)可以定義為源數(shù)據(jù)。因?yàn)榍岸私涌谡?qǐng)求也是由用戶的信息請(qǐng)求來的。對(duì)于應(yīng)用來說，只有用戶的操作不可預(yù)知，其余操作都是可控的。

如果將可控的邏輯封裝后抽離，管理的時(shí)候不需要再直接感知到這些，我們直面的就是用戶的操作和頁面的響應(yīng)。

例如： 以單個(gè)列表頁來說，用戶選擇的篩選項(xiàng)就是源數(shù)據(jù)，而接口請(qǐng)求回來的列表數(shù)據(jù)就是派生數(shù)據(jù)，由接口請(qǐng)求產(chǎn)生的頁面loading態(tài)也可以是派生數(shù)據(jù)也可以是源數(shù)據(jù)。

redux數(shù)據(jù)模型

在使用redux的時(shí)候沒有很好的辦法處理數(shù)據(jù)的層級(jí)關(guān)系，導(dǎo)致store中數(shù)據(jù)的池子越來越大，沒有很強(qiáng)分層的概念，這也是redux小型化困難帶來的，使用的時(shí)候會(huì)下意識(shí)將跨層級(jí)的數(shù)據(jù)存入store。

其次redux沒法很好的描述數(shù)據(jù)與數(shù)據(jù)之間的關(guān)系，有人說computed可以描述數(shù)據(jù)與數(shù)據(jù)之間的關(guān)聯(lián)，簡單意義上是沒問題的，但是computed的局限性，跨redux無法支撐，如果要使用，必須將所有源數(shù)據(jù)匯集到同一個(gè)redux之間，這與最小可用原則是相違背的。

就是因?yàn)閞edux的設(shè)計(jì)模式不夠靈活，導(dǎo)致會(huì)將大量數(shù)據(jù)與數(shù)據(jù)之間的轉(zhuǎn)化邏輯積壓在頁面或者組件內(nèi)部，這對(duì)于視圖層是一種負(fù)擔(dān)。

響應(yīng)式流數(shù)據(jù)模型

為了方便理解，可以和之前一樣將數(shù)據(jù)處理理解為computed，每一個(gè)節(jié)點(diǎn)都可以隨意衍生出一個(gè)新的節(jié)點(diǎn)，但是觸發(fā)整條流的變化又只會(huì)在初始節(jié)點(diǎn)(源數(shù)據(jù))節(jié)點(diǎn)，使用整條流的結(jié)果。

在流模式中對(duì)于組件或頁面外層的數(shù)據(jù)沒有任何層次之分，每個(gè)節(jié)點(diǎn)都是平級(jí)的，如果分層，可以在業(yè)務(wù)上分層，通過不斷的拼接,將業(yè)務(wù)邏輯進(jìn)行串聯(lián)，得出你想要的結(jié)果，相較于原先散亂在各地的邏輯，串聯(lián)的流式邏輯在可讀性上也更優(yōu)。

流式數(shù)據(jù)的優(yōu)點(diǎn)是拆分成本極低，這樣也更符合我們的思想，代碼塊拆分，這樣每一小塊邏輯拆分出一個(gè)節(jié)點(diǎn)，邏輯復(fù)雜度就通過不斷的拆解，變得十分低了，但是又不會(huì)因?yàn)椴鸾獾倪^多，邏輯散亂。

• 沒有固化數(shù)據(jù)的層級(jí)，離散的數(shù)據(jù)，可以自由定義和拼接。
• 以離散的數(shù)據(jù)，將邏輯串流，數(shù)據(jù)靈活之后，邏輯卻是收斂，不會(huì)分散，做到了數(shù)據(jù)精準(zhǔn)的使用。

reducx和rxjs的數(shù)據(jù)管理范圍

總結(jié)

綜上所述，其實(shí)不同的模式帶來的是針對(duì)不同場(chǎng)景的應(yīng)用，redux的快捷應(yīng)用，快捷開發(fā)，數(shù)據(jù)變化的穩(wěn)定，mobx對(duì)于響應(yīng)式的變化，都是各有各的特色。

在寫代碼的時(shí)候，我的感覺像是在構(gòu)建一個(gè)動(dòng)畫的每一幀(視圖)，又要給出每一幀為什么變化(寫邏輯，事件)的感覺，邏輯和視圖混合在一起，對(duì)于整體的把控十分難處理，就像你需要對(duì)于整個(gè)動(dòng)畫的變化都掌握，抽離了視圖和邏輯，邏輯只需要變化數(shù)據(jù)，視圖只需要針對(duì)對(duì)應(yīng)的數(shù)據(jù)變化而已。

參考文章

流動(dòng)的數(shù)據(jù)——使用 RxJS 構(gòu)造復(fù)雜單頁應(yīng)用的數(shù)據(jù)邏輯

精讀《前端數(shù)據(jù)流哲學(xué)》