vivo商城前端架構升級—多端統(tǒng)一探索、實踐與展望篇

本文將會從整體上介紹 vivo 商城在前端維度的多端統(tǒng)一探索和實踐。

從多端價值、為什么要做多端統(tǒng)一、如何滿足多端業(yè)務需求、實踐與創(chuàng)新，簡潔直白的闡述我們在多端統(tǒng)一上所做的一切。

多端的價值可以從技術架構升級和人力資源釋放兩個方面體現(xiàn)。

1、技術架構全面升級

從

到

我們實現(xiàn)了技術架構方案的統(tǒng)一。通過統(tǒng)一，極大的降低了開發(fā)成本、維護成本。同時具備高復用、高效率。

2、釋放大量人力資源

技術架構方案的統(tǒng)一，對業(yè)務的橫向擴張?zhí)峁┝藦姶蟮募夹g支持和可實現(xiàn)保障。

下圖是使用新的技術架構后的開發(fā)人力投入比。

從上圖可以看出，通過技術架構的升級，釋放了可觀的開發(fā)資源。讓釋放的開發(fā)資源去做更多有價值的事情。

這里我先賣個關子，先不談統(tǒng)一，我們來說說多端一詞。多端是什么呢？想必大家都能說個八九不離十。

關于多端，我畫了個圖，如下所示：

從上圖可以看到，線下、pc、wap、APP、微信公眾號、微信小程序等，每一個都可以稱為一個端。知道了多端的含義，現(xiàn)在，我們再回頭看多端統(tǒng)一。

完整的多端統(tǒng)一，要包含以下幾個方面的統(tǒng)一

這里，我們只討論前端的多端統(tǒng)一。

從 PC 瀏覽器，到移動端瀏覽器、到 APP 內(nèi)嵌，再到各個小程序，再到服務端、客戶端。繁榮的生態(tài)，猶如百家爭鳴，百花齊放。然而，繁榮的背后，對前端工程師的挑戰(zhàn)，則與日俱增。

我們承接的端越來越多，新的端不斷的出現(xiàn)，如小程序、快應用等。前端工程師陷入了如下套娃陷阱：

1. 現(xiàn)有代碼、新代碼要適配新的端開發(fā)場景

2. 已經(jīng)適配新的端開發(fā)場景的代碼成為了現(xiàn)有代碼

3. 現(xiàn)有代碼、新代碼要適配新的端開發(fā)場景

4. 循環(huán)...

我們希望解決這種問題，希望做到一套技術架構方案【代碼】，可以覆蓋現(xiàn)在的端和未來的端。

通俗點說，我們希望做到如下圖所示的能力：

在這種前端開發(fā)背景下，多端統(tǒng)一出現(xiàn)了。它是前端的一個未來趨勢，它也是解決上面套娃陷阱的一劑良藥。

隨著時間的推移，各小程序端業(yè)務被逐漸重視起來，尤其是 vivo 商城微信小程序。

業(yè)務方的述求有兩點，如下所示：

第一點：讓現(xiàn)有 vivo 商城微信小程序的核心功能和商城 H5 功能保持一致。

第二點：后續(xù)版本迭代，小程序端和?H5 端同步進行。

而現(xiàn)實是：現(xiàn)有的商城微信小程序，其版本迭代已經(jīng)較大的落后商城 H5 版本了。

老版商城小程序：

新版商城小程序：

根據(jù)業(yè)務方的述求，我們需要做的事情在解決上面兩點的情況下，增加一點，共有三點，如下所示：

在業(yè)務驅動下，我們進行了技術調(diào)研、demo 驗證、mvp 驗證。最終在綜合考慮下，采用了 uni-app 多端架構來解決上面兩個難點。

通過業(yè)務來推動技術的優(yōu)化和改變，在反復應用的過程中，實時反饋改進，最后回報給業(yè)務。在這個過程中，技術和業(yè)務形成了良性閉環(huán)。

NOW. 剩下的事情，就是落地實踐了。

有句名言是這樣說的：實踐是檢驗真理的唯一標準。誠然，成功者的背后，有你看不見的努力和堅持。

1、實踐

在實踐過程中，要考慮的因素很多，列舉如下：

我們可以用一張圖整體概括下，如下圖所示：

下面就介紹下我們是如何處理這些因素的。

2、代碼轉換

我們使用的是開源轉換器 miniprogram-to-uniapp 來做的轉換，然后再通過人工，去解決轉換過程中不匹配的問題。解決方案就是這么樸實無華，也許大家覺得方案很簡單，但是選擇這個解決方案的背后，我們做了詳細的評估，包括和該開源轉換器的作者進行了微信交流。在和作者溝通交流的過程中，我們知道了該轉換器的過去、現(xiàn)在和未來，在當時的情況下，這是一個合適且正確的解決方案。

3、代碼共存

我們通過對項目進行合理的目錄劃分，來達到天然的隔離，如下圖所示：

我們把一些現(xiàn)在還不能適配多端的代碼，統(tǒng)一放到 platforms 目錄下。同時，我們會使用條件編譯來將現(xiàn)在還不能轉換成多端的平臺隔離開。如下圖所示：

4、復用和適配 h5

復用講究的是一個懶字，能直接復用的就果斷復用，不要做二次調(diào)整，保證和 H5 高度一致。

適配講究的是一個以不變應萬變，我們不需要改動 H5 的代碼，我們只需要為他們做一個適配層，如適配 H5 路由，一些不兼容的組件，甚至說適配 window.location 都可以。

從上面介紹的解決方案中，我們可以體會到，處理這些因素的核心秘訣就是下面兩句話：

5、創(chuàng)新

有句話是這樣說的：平凡中孕育著偉大。放在這里，我們換個說法，那就是 實踐中孕育著創(chuàng)新。

在實踐的過程中，我們解決了很多問題。在解決問題的過程中，我們做出了一些令人高興的創(chuàng)新。

• vuex 創(chuàng)新
  

商城 H5 商品詳情頁用 ?vuex 管理數(shù)據(jù)，在將 vuex 移到小程序商品詳情頁中時，發(fā)現(xiàn)一個現(xiàn)象，如下動圖所示：

?

從上面動圖中，我們發(fā)現(xiàn)，在使用 vuex 時 ，我們從 A 商品的詳情頁中點擊 B 商品，進入 B 商品詳情頁。這時，我們點擊左上角返回 A 商品詳情頁，會發(fā)現(xiàn)，此時商品詳情頁已經(jīng)變成 B 商品，也就是說，A 商品的數(shù)據(jù)已經(jīng)沒了。

這是一個非常大的問題，經(jīng)過排查，發(fā)現(xiàn)原因如下：

vuex 的 namespace 默認是一個，無法自動新增 namespace 。當在小程序頁面里面使用 vuex 進行數(shù)據(jù)管理時，由于小程序頁面數(shù)據(jù)機制，在點擊返回時，頁面數(shù)據(jù)使用的是同一個 vuex 的數(shù)據(jù)，從而導致了上面出現(xiàn)的現(xiàn)象。

這里，有人可能要說，在 onShow 生命周期里面，刷新數(shù)據(jù)，不就解決了嗎。其實不然，在這種場景下，進行數(shù)據(jù)刷新是非常不合理的。

我們知道，小程序頁面數(shù)據(jù)在使用 vuex 后，多次進入同一個頁面后，返回會有展示問題。隨后，組內(nèi)進行了討論，綜合權衡后，確定繼續(xù)用 vuex ，通過給 vuex 加一個適配層來解決這個問題。

隨后，組內(nèi)進行了討論，綜合權衡后，確定繼續(xù)用 vuex 。通過給 vuex 加一個適配層來解決這個問題。

首先我們看下，在給 vuex 加一個適配層后，進行上面的操作，會是什么現(xiàn)象。

如下動圖所示：

從上面的動圖，我們可以發(fā)現(xiàn)，在給 vuex 加了一個適配層后。成功的解決了小程序頁面數(shù)據(jù)在使用 vuex 后，多次進入同一個頁面后，點擊返回時，出現(xiàn)的展示問題。

核心方案：通過讓 vuex 支持自動擴展、自動注銷 namespace，來做到更加智能化的數(shù)據(jù)流管理方案。

核心架構圖如下所示：

通過在 store 中自動生成 namespace，保證了同一個頁面進入多次后，每個頁面數(shù)據(jù)都是保留的。當頁面返回時，通過動態(tài)收集父組件的 namespace ，完成了父子組件的 namespace 關聯(lián)。

通過上面的技術方案，我們解決了 vuex 在小程序里面使用時，存在的問題。這里，核心架構方案已經(jīng)給出，具體實現(xiàn)，就不再細述了。

7、解耦創(chuàng)新

我們現(xiàn)在有普通、 秒殺 、 拼團 商品詳情頁，后面還會有其他商品詳情頁，那么我們?nèi)绾螐陀眠@些詳情頁里面的業(yè)務組件呢？

面對上面的問題，大家會有以下思考：

• 不同頁面，業(yè)務組件內(nèi)的數(shù)據(jù)處理是有差別的

• 不同頁面，業(yè)務組件內(nèi)的埋點是不一樣的

• 不同頁面，業(yè)務組件內(nèi)可能存在特定的接口請求

上面的這些思考，大家看過應該是有感觸的，復用業(yè)務組件本身就是一件很困難的事情，如果想徹底的解耦更是難上加難。

我們做了以下幾點：

1. 在上游保證埋點統(tǒng)一，通過設計組件層面的埋點來達到埋點統(tǒng)一。

2. 在組件層面，對特定接口，進行條件判斷。

3. 將業(yè)務組件的數(shù)據(jù)分解成源數(shù)據(jù)和派生數(shù)據(jù)，源數(shù)據(jù)在 vuex 層面保證一致，派生數(shù)據(jù)在業(yè)務組件內(nèi)根據(jù)實際情況進行相應的適配。

4. 對 vuex 進行改造，讓業(yè)務組件和頁面的通信徹底解耦，業(yè)務組件不再需要知道頁面的 vuex 命名空間。

下面是目前已經(jīng)復用的已選彈層組件的組成：

├── components│   ├── sku-number│   ├── sku-product│   ├── sku-service│   ├── sku-spec│   └── ...├── index.js├── index.scss├── index.vue├── mutation-types.js└──?track.js

我們將已選彈層組件的數(shù)據(jù)分為源數(shù)據(jù)和派生數(shù)據(jù)，源數(shù)據(jù)通過 vuex 層面去統(tǒng)一，如下圖所示：

我們?yōu)槊總€詳情頁寫一個 vuex ，同時將相同的部分抽離到 common-detail 中。之后，我們在 vuex 中進行處理，保證不同頁面給出的源數(shù)據(jù)是相同的。這些源數(shù)據(jù)是要傳到業(yè)務組件中的。

如下代碼所示：

// 這是已選彈層業(yè)務組件// 通過 @vivo/smartx 解耦組件和頁面的通信import { mapState, mapGetters, mapMutations, mapActions } from '@vivo/smartx'
// 獲取源數(shù)據(jù)computed: {  ...mapState([    'spuInfo',    'skuInfo'  ]),  ...mapGetters([    'price',    'pageType'  ]),}
methods: {  fn() {    // 策略模式  }}

通過上面的處理，就可以將類似的業(yè)務組件很好的從不同頁面中解耦出來，從而提高代碼的復用性、可維護性以及可擴展性。

這種解耦業(yè)務組件的思想就在于：

每一次創(chuàng)新，都是一次考驗，它總是不經(jīng)意間給你出難點，然后逼迫你，去突破自己，從而創(chuàng)造出更好的東西，循環(huán)往復。

最后，多端架構的 vivo 官方商城微信小程序已經(jīng)上線了。大家可以點擊vivo官方商城體驗一下哦。

本文我們一起回顧了， vivo 商城微信小程序的多端統(tǒng)一之路。從業(yè)務需要，存在價值，到技術實踐與創(chuàng)新，我們希望用技術讓多端之路能夠更加平坦。

??愛心三連擊
1.看到這里了就點個在看支持下吧，你的「點贊，在看」是我創(chuàng)作的動力。
2.關注公眾號程序員成長指北，回復「1」加入Node進階交流群！「在這里有好多 Node 開發(fā)者，會討論 Node 知識，互相學習」！
3.也可添加微信【ikoala520】，一起成長。

“在看轉發(fā)”是最大的支持