????一 前言

Vmo 是我在 18 年發(fā)布的一個(gè)工具庫，用于快速創(chuàng)建數(shù)據(jù)模型，當(dāng)時(shí)我寫了一篇文章《Vmo 前端數(shù)據(jù)模型設(shè)計(jì)》得到過一段時(shí)間的關(guān)注，當(dāng)時(shí)我從事三維裝修相關(guān)的項(xiàng)目。在圖形學(xué)的背景基礎(chǔ)及海量復(fù)雜的數(shù)據(jù)的情況下，自然而然在前端則會(huì)衍生出一種數(shù)據(jù)處理、解析、消費(fèi)的技術(shù)方案，也種下了我對(duì)數(shù)據(jù)模型概念的種子。

簡(jiǎn)單舉個(gè)例子：需要解析一個(gè)三維裝修的房子的數(shù)據(jù)會(huì)有哪些呢?

• 房子(Hourse),樓層(Layer),房間(Room),墻體(Wall),墻面(WallSpace),墻角(Corner),吊頂(Ceiling)，踢腳線(Skirting)，地(Floor，帶厚度)，地面(FloorSpace)，門(Door)，窗(Window)。
• 以及會(huì)延伸出來大量的變體，比如飄窗，直角飄窗，弧形窗，墻洞，樓梯等等。

在解析這些數(shù)據(jù)中存在非常多的相互關(guān)聯(lián)和計(jì)算，比如 房間需要和墻面，墻面需要和墻體關(guān)聯(lián)，墻體和最多 2 個(gè)房間關(guān)聯(lián)，墻角和多個(gè)房間關(guān)聯(lián)，墻角和多個(gè)墻體關(guān)聯(lián)等等

面對(duì)這樣海量、復(fù)雜的數(shù)據(jù)，如果只靠著一個(gè) API 請(qǐng)求的結(jié)果消費(fèi)顯然是非常不可取的方案，先不說這些數(shù)據(jù)能不能正確的解析出來，就說這些數(shù)據(jù)如何維護(hù)，保存時(shí)如何收集到所有數(shù)據(jù)反向序列化給后端都是些頭疼的問題。

當(dāng)然這些問題在當(dāng)時(shí)我們抽象的各個(gè)數(shù)據(jù)模型中得到了解決，如果想了解具體細(xì)節(jié)可以查看我之前的文章。

今天我想講的是，在我加入阿里后，一直在思考的關(guān)于數(shù)據(jù)模型的兩個(gè)問題：

• 是不是數(shù)據(jù)模型這種事情對(duì)于常規(guī)項(xiàng)目沒有使用場(chǎng)景或者價(jià)值呢?常規(guī)的，像一些數(shù)據(jù)查詢，或者填寫一些數(shù)據(jù)提交。這種需求里面有必要使用什么抽象類，什么數(shù)據(jù)模型嗎?
• 為什么在前端圈子里面，很少有看到這方面的內(nèi)容，現(xiàn)在前端圈子里大多都是在走向函數(shù)化，Composition等等，是不是這條路子走的有問題?

在尋覓了 2 年后，主導(dǎo) Lazada 商家端的商品發(fā)布頁面重構(gòu)時(shí)，仿佛找到了一些答案。

二 商品模型

首先在新增一個(gè)商品的過程中，實(shí)際上是用戶在以客戶端的形式制作一組商品數(shù)據(jù)，常規(guī)的前端視角來看就是提交一份“JSON”。

而編輯就是通過 API 拉取這份“JSON”解析到 Form 表單中，讓用戶進(jìn)行編輯后，再將這份“JSON”提交。

那么粗略的將數(shù)據(jù)抽象為模型將會(huì)成為這樣：

??

Well，到目前為止，我們做的事情都感覺像是在脫褲子放屁，多此一舉。哈哈哈，各位看官暫且勿噴，稍安勿躁 。

那么為什么需要把這些數(shù)據(jù)抽象為一個(gè)類呢?我拿一下幾個(gè) Case 來說明：

1 請(qǐng)求數(shù)據(jù) & 單元測(cè)試

很多時(shí)候，前端把對(duì)數(shù)據(jù)的請(qǐng)求和處理是寫在組件中的，更優(yōu)一點(diǎn)可能會(huì)封裝在某個(gè)聚類里面，或者某個(gè) Hook 里面，調(diào)用時(shí)輕巧的拿到狀態(tài)和數(shù)據(jù)。

像商品這樣的數(shù)據(jù)請(qǐng)求方式會(huì)存在多種：草稿中獲取，編輯中獲取，某個(gè)類目中獲取(不同類目下，商品屬性不同)。

每種獲取方式請(qǐng)求的接口和參數(shù)組合方式可能不同，但最后前端消費(fèi)的產(chǎn)物卻是相同的。按照策略模式來說，對(duì)于一個(gè)商品模型的獲取只是使用了不同的策略，但產(chǎn)物卻是一致的，消費(fèi)端無論調(diào)用何種方式，獲取到的結(jié)果都是可靠的 Product 模型類。

有經(jīng)驗(yàn)的前端都知道，很多時(shí)候，在一個(gè)項(xiàng)目在一輪輪的迭代后，我們的接口數(shù)據(jù)往往會(huì)存在部分?jǐn)?shù)據(jù)需要前端做一定處理或者轉(zhuǎn)換。

面對(duì)這樣的數(shù)據(jù)處理，如果放在一個(gè)組件或者 Hook 中，是不太合適的，在做單元測(cè)試或者數(shù)據(jù)消費(fèi)的時(shí)候都可能會(huì)給我們帶來一些阻力。

在我看來，調(diào)試一個(gè)數(shù)據(jù)問題最好的辦法，就是寫一個(gè)單元測(cè)試，對(duì)單元測(cè)試預(yù)期的結(jié)果進(jìn)行調(diào)試，往往比我們?cè)跒g覽器中 Mock 一份數(shù)據(jù)調(diào)試數(shù)據(jù)更高效，對(duì)將來的穩(wěn)定性也更有幫助。

安全感，數(shù)據(jù)消費(fèi)起來，一個(gè)類和一份 JSON 給開發(fā)者帶來的安全感和爽感是完全不同的。消費(fèi)過數(shù)據(jù)模型 或者 次一點(diǎn) 消費(fèi)過Interface的小伙伴，我相信對(duì)這一點(diǎn)是非常認(rèn)同的。

哈哈，說到這里有些小伙伴可能要問了，你說的這個(gè)我們用Interface也能達(dá)到同樣的效果呀。好，咱們繼續(xù)...

2 計(jì)算性消費(fèi)數(shù)據(jù)

什么叫計(jì)算性消費(fèi)數(shù)據(jù)的，說的簡(jiǎn)單點(diǎn)，就比如：

class Person1 { 
   fistName = "Wang"; 
   lastName = "Yee"; 
  
   get fullName() { 
     return `${this.lastName} ${this.fistName}`; // Yee Wang 
   } 
  
   get fullNameCN() { 
     return `${this.fistName} ${this.lastName}`; // Wang Yee 
   } 
 }

上面這個(gè)例子非常經(jīng)典且清晰，元數(shù)據(jù)中可能只是些基本數(shù)據(jù)，但是很多時(shí)候前端需要根據(jù)不同場(chǎng)景來進(jìn)行元數(shù)據(jù)組裝，以往這些數(shù)據(jù)往往會(huì)被封裝為各個(gè)方法，或者被當(dāng)做 template 寫在組件中，散落在各個(gè)角落，每當(dāng)用到這份數(shù)據(jù)時(shí)可能又會(huì)重新按照?qǐng)鼍敖M裝一遍。往往這種時(shí)候就會(huì)存在 需求缺失，比如某情況下需要將之前所有消費(fèi)到 fullName 的地方改為小寫。

拿到商品發(fā)布來說，計(jì)算性消費(fèi)數(shù)據(jù)到底有哪些應(yīng)用場(chǎng)景呢?

在此之前，我想先解釋一下SKU這個(gè)數(shù)據(jù)模型，它其中最核心的元數(shù)據(jù)是：value: Map

??

按照上圖這個(gè)表格中所示，可以看到該商品共有 6 個(gè) SKU，第一個(gè) SKU 所對(duì)應(yīng)的SKU模型數(shù)據(jù)應(yīng)為：

??

class SKU { 
   value = new Map([ 
     [ 
       new SKUProperty({ id: 1, label: "Color Family" }), 
       new SKUValue({ id: 101, label: "Red" }), 
     ], 
     [ 
       new SKUProperty({ id: 2, label: "Size" }), 
       new SKUValue({ id: 201, label: "33" }), 
     ], 
   ]); 
   price: string; 
 }

像這樣一個(gè) SKU Model，它所具備的元數(shù)據(jù)已經(jīng)可以清晰描述當(dāng)前 SKU，而且可以通過 SKU 的擴(kuò)展方法做到很多有用的數(shù)據(jù)，比如：

• getProperties() 獲取該 SKU 有所有屬性，如：Color Family，Size。
• getValues() 獲取該 SKU 所有Value，如：Red，33。
• isEqual(anotherSKU: SKU): boolean 比較一個(gè) SKU 是否和當(dāng)前 SKU 完全相同，這在后續(xù)的數(shù)據(jù)合并中非常有用。
• getValueByPropertyId(id: string) 通過 PropertyId，獲取一個(gè) SKUValue。

相比與只是一個(gè) Object 對(duì)象來說，數(shù)據(jù)模型能夠帶來非常多的數(shù)據(jù)處理和數(shù)據(jù)擴(kuò)展能力，當(dāng)某種情況下需要消費(fèi)由該數(shù)據(jù)產(chǎn)生的計(jì)算性消費(fèi)數(shù)據(jù)時(shí)，可以很輕易的進(jìn)行擴(kuò)展使用，對(duì)于數(shù)據(jù)結(jié)構(gòu)也有更好的預(yù)期和掌控力。

結(jié)合對(duì)該數(shù)據(jù)模型的單元測(cè)試，就可以清晰快速的開發(fā)數(shù)據(jù)層，當(dāng)數(shù)據(jù)層可靠后，在視圖層消費(fèi)就會(huì)變得行云流水，得心應(yīng)手了。

舉個(gè)單元測(cè)試的例子：

it("alias sku equal", () => { 
   const data = [ 
     { 
       text: "300MB", 
       value: 2988, 
       name: "p-1", 
     }, 
     { 
       text: "Blue", 
       value: 2888, 
       alias: "Blue1", 
       name: "p-2", 
     }, 
   ]; 
   const sku = SKU.fromData(data); 
   expect( 
     sku.isEqual( 
       SKU.fromData([ 
         { 
           text: "300MB", 
           value: 2988, 
           name: "p-1", 
         }, 
         { 
           text: "Blue", 
           value: 2888, 
           alias: "Blue2", 
           name: "p-2", 
         }, 
       ]) 
     ) 
   ).toBeFalsy(); 
 });

這種SKU，是一種類型較為特殊的SKU，它其中會(huì)存在 alias 字段，當(dāng)有這種字段時(shí)，在做SKU比對(duì)時(shí)，不但要對(duì) SKUProperty，SKUValue 的ID做比對(duì)，還需要對(duì) alias 字段做比對(duì)。

所以按照上面的單測(cè)來看，結(jié)果應(yīng)該是 false，因?yàn)檫@兩份數(shù)據(jù)中的alias是不同的。沒辦法，這是一個(gè)業(yè)務(wù)需求。

如果在視圖層做數(shù)據(jù)比對(duì)時(shí)，使用的是純數(shù)據(jù)進(jìn)行比對(duì)，很有可能漏掉這部分邏輯，這就會(huì)導(dǎo)致項(xiàng)目變得捉襟見肘，拆東墻補(bǔ)西墻。

反正，在消費(fèi)層遇到很多的需要對(duì)數(shù)據(jù)處理或判斷時(shí)，大可以將這部分能力交給數(shù)據(jù)模型來處理，由數(shù)據(jù)模型來保證數(shù)據(jù)的穩(wěn)定性。

3 數(shù)據(jù)關(guān)系

使用數(shù)據(jù)模型，還可以幫你清晰管理數(shù)據(jù)關(guān)系，比如商品和SKU之間，SKU和SKUProperty，SKUValue 之間的關(guān)系。

我舉個(gè)具體案例：

??

這是一個(gè)商品編輯時(shí)組 笛卡爾積(Cartesian product) 的過程，當(dāng)我們的SKU屬性被用戶添加或者修改時(shí)，將會(huì)觸發(fā)笛卡爾積的重新計(jì)算出最新的排列組合結(jié)果。

比如當(dāng)用戶新增一個(gè)尺碼為35時(shí)，笛卡爾積將會(huì)多出兩項(xiàng)組合結(jié)果。同理，如果當(dāng)維度增加一列時(shí)，比如添加材質(zhì)維度，將會(huì)產(chǎn)生更多SKU結(jié)果。

以往，前端開發(fā)者總會(huì)將這部分計(jì)算過程封裝成為一個(gè)數(shù)學(xué)方法，放在utils中隨時(shí)調(diào)用，這看起沒什么問題。

如果將這個(gè)過程看做是，一個(gè) SKUCollection 數(shù)據(jù)模型的構(gòu)建過程的話，一切就會(huì)將變得順理成章：

test('sku calculate whether valid', () => { 
   const skuCellection = SKUCollection.fromData({ 
     'p-3xxxx': [ 
       { 
         text: '300MB', 
         value: 2, 
       }, 
       { 
         text: '128GB', 
         value: 3, 
       }, 
     ], 
     'p-4xxxx': [ 
       { 
         text: 'Blue', 
         value: 3, 
       }, 
       { 
         text: 'Red', 
         value: 15, 
       }, 
       { 
         text: 'Green', 
         value: 1, 
       }, 
     ], 
   }); 
  
   expect( 
     skuCellection.value 
   ).toEqual( 
     // 6 SKU Model 
   );  
 });

有了這樣一個(gè)數(shù)據(jù)模型結(jié)構(gòu)后，就可以清晰的通過數(shù)據(jù)模型來調(diào)用其相關(guān)的數(shù)據(jù)和計(jì)算性數(shù)據(jù)。

另外，不同的數(shù)據(jù)模型雖然相互依賴，但對(duì)數(shù)據(jù)解析和計(jì)算性數(shù)據(jù)缺相互獨(dú)立，可以做到獨(dú)立使用和單元測(cè)試。

??

三 異常模型

商品發(fā)布本質(zhì)上是一個(gè)較為復(fù)雜的表單提交頁面。由于字段多，交互復(fù)雜等原因，在產(chǎn)品設(shè)計(jì)過程中，就已經(jīng)將很多字段先拆分為不同模塊，來減輕用戶心理負(fù)擔(dān)。

比如會(huì)存在：基礎(chǔ)信息，商品屬性，詳描，運(yùn)費(fèi)等。

在填寫過程中，會(huì)存在部分 前端校驗(yàn) + 后端校驗(yàn) 的場(chǎng)景。

在數(shù)據(jù)提交或者其他數(shù)據(jù)寫入過程中，后端同時(shí)會(huì)處理字段校驗(yàn)，當(dāng)后端發(fā)現(xiàn)某個(gè)字段填寫錯(cuò)誤時(shí)，服務(wù)端將返回錯(cuò)誤信息及錯(cuò)誤字段信息。

為了更好的交互體驗(yàn)，前端將會(huì)根據(jù)返回獲取到字段信息，定位到對(duì)應(yīng)的字段位置，顯示錯(cuò)誤信息并報(bào)紅，另外還需要根據(jù)當(dāng)前字段判斷其所歸屬的模塊進(jìn)行報(bào)錯(cuò)。

??

還有一種情況是：服務(wù)端的第一層校驗(yàn)通過，調(diào)用其他商品上游鏈路時(shí)拋出異常，此時(shí)上游鏈路可能已經(jīng)丟失字段信息，面對(duì)這樣的異常數(shù)據(jù)，前端需要展示在表單頂部，并且提供traceId，以便追蹤定位異常。

??

就商品發(fā)布來說，顯而易見的"保存"的動(dòng)作是一個(gè)需要處理異常的情況，所以我們會(huì)在提交的地方寫上很多后端返回異常時(shí)的處理邏輯。

當(dāng)有一天，有另外一個(gè)迭代需要寫入操作時(shí)，同樣也會(huì)產(chǎn)生異常的情況，這些的異常情況再次處理時(shí)又會(huì)有很多數(shù)據(jù)轉(zhuǎn)換和錯(cuò)誤顯示的邏輯。

如果收到這份后端返回?cái)?shù)據(jù)，將他轉(zhuǎn)換為異常數(shù)據(jù)模型，然后交由視圖層消費(fèi)，這樣會(huì)讓所有異常模型下需要處理的邏輯復(fù)用避免交互邏輯丟失。

當(dāng)然，視圖層如何更巧妙的消費(fèi)該數(shù)據(jù)模型又是另外一個(gè)有意思的設(shè)計(jì)，此處暫且不表，后面我還會(huì)寫一篇專門介紹商品發(fā)布的視圖層狀態(tài)管理設(shè)計(jì)。

四 總結(jié)

在商品發(fā)布中，除了上述提到的幾個(gè)數(shù)據(jù)模型以外，其實(shí)還構(gòu)建了一些其他類型的數(shù)據(jù)模型，如：運(yùn)費(fèi)模型，商品質(zhì)量分模型，類目推薦模型等... 然后由這些多個(gè)子模型共同組合成為一個(gè)商品的模型。

這樣的數(shù)據(jù)模型在消費(fèi)起來，開發(fā)者其實(shí)不會(huì)太過關(guān)心究竟需要請(qǐng)求什么API，返回的數(shù)據(jù)究竟是什么樣的，他們的返回是否要處理、轉(zhuǎn)換、兼容等問題。

同時(shí)，這樣高質(zhì)量的數(shù)據(jù)模型其實(shí)不依賴于視圖層的框架，它可以被抽離作為一個(gè)獨(dú)立的包來管理維護(hù)，然后在其他頁面引入使用，比如商品域可能遇到的：商品管理，商品選擇，運(yùn)費(fèi)編輯，商品質(zhì)量分預(yù)覽等等...

回到開頭，我提到的問題：

• 是不是數(shù)據(jù)模型這種事情對(duì)于常規(guī)項(xiàng)目沒有使用場(chǎng)景或者價(jià)值呢?常規(guī)的，像一些數(shù)據(jù)查詢，或者填寫一些數(shù)據(jù)提交。這種需求里面有必要使用什么抽象類，什么數(shù)據(jù)模型嗎?
• 為什么在前端圈子里面，很少有看到這方面的內(nèi)容，現(xiàn)在前端圈子里大多都是在走向函數(shù)化，Composition等等，是不是這條路子走的有問題?

首先肯定的是，在我所使用的過程中，數(shù)據(jù)模型確實(shí)非常清晰，有力，牢固的解決了我所面到的業(yè)務(wù)問題，所以它是有價(jià)值的。

至于和常規(guī)的需求，到底應(yīng)該用什么好呢?哈哈，這個(gè)問題有個(gè)比較無賴的回答，小孩子才考慮什么要什么不要，成年人什么都要，沒有什么技術(shù)是非黑即白的。

Vite 就只能在 Vue 的項(xiàng)目里面使用嗎?

什么合適用什么，簡(jiǎn)單的數(shù)據(jù)查詢展示不需要這么精細(xì)的數(shù)據(jù)處理，當(dāng)然可以直接拿來即用咯，解決業(yè)務(wù)問題的方法就是好方法!

至于Composition API，其實(shí)在商品發(fā)布的重構(gòu)過程中，基本絕大多數(shù)都是使用這種設(shè)計(jì)思路來實(shí)現(xiàn)的，這樣的設(shè)計(jì)確實(shí)能讓我們清晰的分辨每個(gè)方法是干什么的，是否會(huì)影響交互，以及這樣的交互是在做什么，每個(gè)交互都在一個(gè)位置維護(hù)和處理，后面我會(huì)單獨(dú)寫一篇介紹。

實(shí)踐過程中發(fā)現(xiàn)，數(shù)據(jù)模型和Composition API并不沖突，一個(gè)是用來處理數(shù)據(jù)層，一個(gè)是用來處理視圖層，它們相輔相成結(jié)合一些訂閱模式的設(shè)計(jì)，就會(huì)讓整個(gè)項(xiàng)目的劃分異常清晰，我十分建議大家在以后遇到單點(diǎn)項(xiàng)目較為復(fù)雜時(shí)能夠使用這一套思路來解決業(yè)務(wù)問題!