建站
咨詢
售后
建站咨詢
新聞中心
1. 什么是數(shù)據(jù)流
什么是流?
什么是數(shù)據(jù)流
依據(jù)之前的定義，數(shù)據(jù)流即隨時(shí)間變化的一個(gè)數(shù)據(jù)集合。
10年積累的做網(wǎng)站、網(wǎng)站設(shè)計(jì)經(jīng)驗(yàn)，可以快速應(yīng)對(duì)客戶對(duì)網(wǎng)站的新想法和需求。提供各種問(wèn)題對(duì)應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識(shí)你，你也不認(rèn)識(shí)我。但先網(wǎng)站設(shè)計(jì)后付款的網(wǎng)站建設(shè)流程，更有賓川免費(fèi)網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。
前端針對(duì)于現(xiàn)狀mvvm模式下，數(shù)據(jù)即頁(yè)面，在多數(shù)情況下，數(shù)據(jù)不變頁(yè)面不變。那么我們轉(zhuǎn)換一下，數(shù)據(jù)==>頁(yè)面，數(shù)據(jù)流是否可以等價(jià)為一個(gè)頁(yè)面的變化集合。這個(gè)是什么，就是我們的業(yè)務(wù)邏輯。
當(dāng)然，前面的假設(shè)，是經(jīng)過(guò)很多轉(zhuǎn)化，其實(shí)有很多漏洞和錯(cuò)誤。但是可以作為一個(gè)簡(jiǎn)單的參考。
這個(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ù)倉(cāng)庫(kù)，對(duì)數(shù)據(jù)進(jìn)行保護(hù)，保障數(shù)據(jù)穩(wěn)定可靠。
可以簡(jiǎn)單理解redux是一個(gè)帶保護(hù)的全局使用的Context(useContext)。
針對(duì)于原生的提供了數(shù)據(jù)保護(hù)(dispatch+reducer)，對(duì)于更改只允許使用dispatch進(jìn)行更改。能夠保障可回溯性，數(shù)據(jù)來(lái)源清晰，能夠十分良好的隔絕副作用。
使用方面：
- 優(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í)，通過(guò)計(jì)算狀態(tài)，頁(yè)面進(jìn)行變化，并且根據(jù)observable，自動(dòng)根據(jù)依賴執(zhí)行更新。雖然有了action，但還是沒(méi)有強(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)，可以簡(jiǎ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沒(méi)有mobx從數(shù)據(jù)變化到頁(yè)面變化這個(gè)功能，可以使用useState和useEffect實(shí)現(xiàn)或者現(xiàn)成的三方庫(kù)rxjs-hooks。
rxjs的優(yōu)勢(shì)是，抽離所有數(shù)據(jù)源之后，剩余全部都是邏輯問(wèn)題，副作用在抽離數(shù)據(jù)源的時(shí)候就已經(jīng)剝離干凈了(因?yàn)橥獠扛弊饔脭?shù)據(jù)也可以抽離成rxjs的節(jié)點(diǎn))，剩下就通過(guò)api和純函數(shù)來(lái)編寫(xiě)具體的邏輯了。
又因?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)行讀寫(xiě)數(shù)據(jù)，對(duì)于尾部節(jié)點(diǎn)直接讀取數(shù)據(jù)就可以，大部分邏輯全部被抽離出了組件。
使用方面：
- 優(yōu)點(diǎn)：邏輯拆分簡(jiǎn)便，純函數(shù)式編程。
- 缺點(diǎn)：數(shù)據(jù)拆分復(fù)雜，重設(shè)計(jì)，api學(xué)習(xí)和理解成本高。
理想情況下，頁(yè)面就是一個(gè)個(gè)無(wú)狀態(tài)組件，行為改變數(shù)據(jù)。數(shù)據(jù)變化又觸發(fā)邏輯變更，邏輯變更數(shù)據(jù)。數(shù)據(jù)又回流到頁(yè)面，這是一個(gè)整體的閉環(huán)，以數(shù)據(jù)為核心，完美的做到數(shù)據(jù)驅(qū)動(dòng)頁(yè)面。
新星 Recoil
recoil是facebook官方推薦的一個(gè)狀態(tài)管理庫(kù)，作為一個(gè)“新成員”，recoil相比于之前的三種狀態(tài)管理方式，做了很多取舍。它有節(jié)點(diǎn)的概念，有atom(原子數(shù)據(jù))和selector(派生數(shù)據(jù))但是不和mobx一樣，recoil是基于Immutable(不變)模式。
recoil的基礎(chǔ)思想是atom數(shù)據(jù)之間沒(méi)有關(guān)聯(lián)，產(chǎn)生的關(guān)聯(lián)數(shù)據(jù)全部由selector來(lái)產(chǎn)生，atom的變動(dòng)，相關(guān)的selector隨之變動(dòng)，這個(gè)和響應(yīng)式流的思想一致的。
recoil的優(yōu)勢(shì)，貼合react，可以將recoil的實(shí)現(xiàn)當(dāng)作通過(guò)useMemo包裝的context，api使用可以滿足只讀，只寫(xiě)進(jìn)行拆分，可以十分貼合最優(yōu)渲染，降低無(wú)用的渲染。
上述前三種數(shù)據(jù)流沒(méi)有什么優(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ù)之間推行的是最小可用原則，分而治之，這才更利于我們開(kāi)發(fā)和維護(hù)。
個(gè)人把產(chǎn)生數(shù)據(jù)的起始數(shù)據(jù)定義為源數(shù)據(jù)。有些數(shù)據(jù)可以互相轉(zhuǎn)換，那如何定義源數(shù)據(jù)???
定義源數(shù)據(jù)
從組件(頁(yè)面)視角看一下數(shù)據(jù)。
- 面向接口編程
大部分情況下前端和后端之間的數(shù)據(jù)交互就只有接口這一種。又因?yàn)檎鎸?shí)的所有數(shù)據(jù)都是從服務(wù)端獲取的數(shù)據(jù)，所以下意識(shí)的以服務(wù)端接口為數(shù)據(jù)起始。數(shù)據(jù)處理的鏈路較長(zhǎng)，范圍變大對(duì)于個(gè)人的理解要求是十分高的，個(gè)人認(rèn)為這對(duì)于一個(gè)大型應(yīng)用是不健康的。
- 面向數(shù)據(jù)編程
分離接口請(qǐng)求，只關(guān)心組件狀態(tài)，對(duì)于組件方面，任何數(shù)據(jù)不將其做區(qū)分，數(shù)據(jù)來(lái)就渲染。
個(gè)人將用戶可交互的數(shù)據(jù)可以定義為源數(shù)據(jù)。因?yàn)榍岸私涌谡?qǐng)求也是由用戶的信息請(qǐng)求來(lái)的。對(duì)于應(yīng)用來(lái)說(shuō)，只有用戶的操作不可預(yù)知，其余操作都是可控的。
如果將可控的邏輯封裝后抽離，管理的時(shí)候不需要再直接感知到這些，我們直面的就是用戶的操作和頁(yè)面的響應(yīng)。
例如： 以單個(gè)列表頁(yè)來(lái)說(shuō)，用戶選擇的篩選項(xiàng)就是源數(shù)據(jù)，而接口請(qǐng)求回來(lái)的列表數(shù)據(jù)就是派生數(shù)據(jù)，由接口請(qǐng)求產(chǎn)生的頁(yè)面loading態(tài)也可以是派生數(shù)據(jù)也可以是源數(shù)據(jù)。
redux數(shù)據(jù)模型
在使用redux的時(shí)候沒(méi)有很好的辦法處理數(shù)據(jù)的層級(jí)關(guān)系，導(dǎo)致store中數(shù)據(jù)的池子越來(lái)越大，沒(méi)有很強(qiáng)分層的概念，這也是redux小型化困難帶來(lái)的，使用的時(shí)候會(huì)下意識(shí)將跨層級(jí)的數(shù)據(jù)存入store。
其次redux沒(méi)法很好的描述數(shù)據(jù)與數(shù)據(jù)之間的關(guān)系，有人說(shuō)computed可以描述數(shù)據(jù)與數(shù)據(jù)之間的關(guān)聯(lián)，簡(jiǎn)單意義上是沒(méi)問(wèn)題的，但是computed的局限性，跨redux無(wú)法支撐，如果要使用，必須將所有源數(shù)據(jù)匯集到同一個(gè)redux之間，這與最小可用原則是相違背的。
就是因?yàn)閞edux的設(shè)計(jì)模式不夠靈活，導(dǎo)致會(huì)將大量數(shù)據(jù)與數(shù)據(jù)之間的轉(zhuǎn)化邏輯積壓在頁(yè)面或者組件內(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ì)于組件或頁(yè)面外層的數(shù)據(jù)沒(méi)有任何層次之分，每個(gè)節(jié)點(diǎn)都是平級(jí)的，如果分層，可以在業(yè)務(wù)上分層，通過(guò)不斷的拼接,將業(yè)務(wù)邏輯進(jìn)行串聯(lián)，得出你想要的結(jié)果，相較于原先散亂在各地的邏輯，串聯(lián)的流式邏輯在可讀性上也更優(yōu)。
流式數(shù)據(jù)的優(yōu)點(diǎn)是拆分成本極低，這樣也更符合我們的思想，代碼塊拆分，這樣每一小塊邏輯拆分出一個(gè)節(jié)點(diǎn)，邏輯復(fù)雜度就通過(guò)不斷的拆解，變得十分低了，但是又不會(huì)因?yàn)椴鸾獾倪^(guò)多，邏輯散亂。
- 沒(méi)有固化數(shù)據(jù)的層級(jí)，離散的數(shù)據(jù)，可以自由定義和拼接。
- 以離散的數(shù)據(jù)，將邏輯串流，數(shù)據(jù)靈活之后，邏輯卻是收斂，不會(huì)分散，做到了數(shù)據(jù)精準(zhǔn)的使用。
reducx和rxjs的數(shù)據(jù)管理范圍
總結(jié)
綜上所述，其實(shí)不同的模式帶來(lái)的是針對(duì)不同場(chǎng)景的應(yīng)用，redux的快捷應(yīng)用，快捷開(kāi)發(fā)，數(shù)據(jù)變化的穩(wěn)定，mobx對(duì)于響應(yīng)式的變化，都是各有各的特色。
在寫(xiě)代碼的時(shí)候，我的感覺(jué)像是在構(gòu)建一個(gè)動(dòng)畫(huà)的每一幀(視圖)，又要給出每一幀為什么變化(寫(xiě)邏輯，事件)的感覺(jué)，邏輯和視圖混合在一起，對(duì)于整體的把控十分難處理，就像你需要對(duì)于整個(gè)動(dòng)畫(huà)的變化都掌握，抽離了視圖和邏輯，邏輯只需要變化數(shù)據(jù)，視圖只需要針對(duì)對(duì)應(yīng)的數(shù)據(jù)變化而已。
參考文章
流動(dòng)的數(shù)據(jù)——使用 RxJS 構(gòu)造復(fù)雜單頁(yè)應(yīng)用的數(shù)據(jù)邏輯
精讀《前端數(shù)據(jù)流哲學(xué)》
文章名稱：聊聊前端數(shù)據(jù)流選型
文章位置：http://www.5511xx.com/article/cdpjhcp.html
