Page Maker是我在公司參與時(shí)間最長(zhǎng)的一個(gè)項(xiàng)目了，自打?qū)嵙?xí)期做了webIM，轉(zhuǎn)正之后不久，就開(kāi)始參與了PageBuilder項(xiàng)目的開(kāi)發(fā)，前前后后大概經(jīng)歷了兩年的時(shí)間，后來(lái)由于公司業(yè)務(wù)調(diào)整，已經(jīng)在今年初逐步將項(xiàng)目交接了出去。雖然現(xiàn)在不再參與項(xiàng)目的維護(hù)，但是從這么長(zhǎng)時(shí)間的開(kāi)發(fā)過(guò)程中，還是學(xué)到了很多東西，也讓我成長(zhǎng)了很多。其實(shí)最關(guān)鍵的，并不是具體解決了什么問(wèn)題，而是解決問(wèn)題的思路與方法。

PM 的產(chǎn)品定位是一個(gè)平臺(tái)，他所提供的核心能力就是頁(yè)面的可視化構(gòu)建，通過(guò)拖拖拽拽，就可以生成一個(gè)頁(yè)面，并所見(jiàn)即所得。為公司的各產(chǎn)品先以及后續(xù)的ISV提供穩(wěn)定 可靠 自由的頁(yè)面定制化能力，以此滿足客戶的多樣化需求。

在實(shí)際的開(kāi)發(fā)過(guò)程中，我們遇到以及需要解決的問(wèn)題有：

(相關(guān)資料圖)

組件化元數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)組件開(kāi)發(fā)規(guī)范運(yùn)行態(tài)資源加載與性能優(yōu)化基礎(chǔ)依賴(lài)管理

其實(shí)每個(gè)點(diǎn)都能單獨(dú)寫(xiě)一篇文章的，這里就只簡(jiǎn)單總結(jié)了。

組件化

在PM的實(shí)現(xiàn)中，頁(yè)面組件化是一個(gè)非常重要的前提，所以我們抽象出了兩個(gè)概念，即：

布局組件視圖組件

布局組件用以實(shí)現(xiàn)頁(yè)面布局，而視圖組件承載著業(yè)務(wù)數(shù)據(jù)，并以多樣化的形式展現(xiàn)給用戶。所以頁(yè)面長(zhǎng)得好不好看，直接取決于視圖組件。 另外，為了提高視圖組件的可擴(kuò)展性，以及凸顯PM所強(qiáng)調(diào)的 可配置的能力，我們還抽象出了一個(gè)組件類(lèi)型，即 屬性組件。

有了屬性組件，實(shí)施人員就可以給視圖組件配置不同的屬性，比如數(shù)據(jù)源，展示形式，等等，對(duì)于視圖組件來(lái)說(shuō)，所有可變，可配置的，都以通過(guò)屬性組件來(lái)實(shí)現(xiàn)。通過(guò) PM平臺(tái)，將屬性組件和視圖關(guān)聯(lián)展示到頁(yè)面上，并最終呈現(xiàn)給用戶。

元數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)

基于元數(shù)據(jù)的應(yīng)用設(shè)計(jì)的最大的好處就是可描述和可擴(kuò)展。我們將頁(yè)面抽像為一套元數(shù)據(jù)結(jié)構(gòu)，而pb就是這套元數(shù)據(jù)的解析器。保存頁(yè)面，實(shí)質(zhì)上就是保存了一份元數(shù)據(jù)的實(shí)例。

{/****組件列表: 每往頁(yè)面中拖入一個(gè)組件，都會(huì)在該屬性下新增一條字段，用于描述該組件****/"componentList": [{"editableData": string,//組件的可編輯屬性    "cType": string,       //組件名稱(chēng)    "hasCustomProps": Boolean, //組件是否有自定義屬性    "isContainer":Boolean,//是否是容器組件    "isSubcomponent":Boolean,//是否是子組件    "id": string,//組件id 唯一標(biāo)識(shí)    "parentId": string,//父級(jí)ID    "componentHolderKey":string,//對(duì)應(yīng)tab容器組件的tab    "appId":number,//組件屬性應(yīng)用的ID    "deletable":Boolean,//組件是否可以被刪除    "url":string,//iframe組件URL地址，之前ocean組件用的}],/*****頁(yè)面數(shù)據(jù)信息****/"pageSettings": {"title": "AAA",//頁(yè)面名稱(chēng)     "template": "Classic",//頁(yè)面模版       "layout": "grid"http://布局類(lèi)型 grid / vertical},//頁(yè)面的可編輯屬性pageProperty:{"editableData": {},}/**section列表，注意 有的section是沒(méi)有位置信息的，如容器組件內(nèi)的組件,是根據(jù)數(shù)組順序依次由上而下排列**/"sectionList": [{"id": string,//唯一的標(biāo)識(shí)       "targetLayout": string,//所屬的工作區(qū)       "x":number,//x坐標(biāo)       "y":number,//y坐標(biāo)       "w":number,//w 寬度       "h":number//h 高度}, {"id": "8d227680-f26a-11e6-9457-8f2c27c19ddf","targetLayout": "default1"}]}

組件開(kāi)發(fā)規(guī)范

在這個(gè)問(wèn)題下，細(xì)分的問(wèn)題還是挺多的比如：

1. 技術(shù)選型

這個(gè)其實(shí)沒(méi)有太多可說(shuō)的，公司整個(gè)平臺(tái)都采取的React框架，所以為了保持統(tǒng)一，當(dāng)然就是直接采用React

2. 組件開(kāi)發(fā)模版

這里的模版設(shè)計(jì)所遵循的原則應(yīng)該是盡量簡(jiǎn)潔，符合常規(guī)的開(kāi)發(fā)習(xí)慣，并將細(xì)節(jié)封裝好隱藏在內(nèi)部。我們會(huì)提供一條龍的服務(wù)，包括但不限于構(gòu)建方案 組件注冊(cè) 以及對(duì)接CI服務(wù)，對(duì)于業(yè)務(wù)方來(lái)講，只需要關(guān)注于組件的開(kāi)發(fā)即可。另外，模版設(shè)計(jì)時(shí)，一定要遵循模塊化 分層設(shè)計(jì)的思想，盡量減少后續(xù)模塊升級(jí)所帶來(lái)的遷移成本。

#源代碼目錄，項(xiàng)目基礎(chǔ)結(jié)構(gòu)，里面列的文件必須按照這個(gè)結(jié)構(gòu)存在，其他可按照自己的需求安排。/src    #export組件的文件，必須存在    index.js    #Page Builder屬性配置代碼存放的目錄    /props        #export 屬性組件文件        index.js#包信息描述package.json#文檔README.md#git忽略文件列表.gitignore#npm忽略文件列表.npmignore# webpack配置 可選 支持自定義擴(kuò)展webpack.config.js

4. cli工具

前端工程化設(shè)計(jì)中，一個(gè)很重要的原則就是自動(dòng)化，將所有重復(fù)性的，工程化的工作，交給程序完成，從而盡可能的提升工作效率。所以我們開(kāi)發(fā)cli工具，將組件注冊(cè) git項(xiàng)目搭建，以及生成本地開(kāi)發(fā)模版的任務(wù)全部集成在cli工具中，開(kāi)發(fā)人員一分鐘的時(shí)間，就可以開(kāi)始新組件的開(kāi)發(fā)

5.css 模塊化

相對(duì)于JS的發(fā)展的來(lái)講，CSS的進(jìn)度確實(shí)緩慢了些。因?yàn)镻M頁(yè)面上的組件都是獨(dú)立構(gòu)建的，但是會(huì)放在同一個(gè)運(yùn)行態(tài)下，所以很容易出現(xiàn)樣式覆蓋的問(wèn)題。為了保持樣式的穩(wěn)定，作為平臺(tái)，必須提供統(tǒng)一的css 模塊化方案。經(jīng)過(guò)技術(shù)方案的調(diào)研和對(duì)比，最終采取了styled-component。至于為什么不采用css module，是因?yàn)樗膆ash是在構(gòu)建過(guò)程完成計(jì)算的，而不是運(yùn)行時(shí)，所以不能從根本上解決PM平臺(tái)所面臨的問(wèn)題。

6. 版本管理

對(duì)于組件的版本管理，我們沒(méi)有采取hash，轉(zhuǎn)而采用了npm包版本的方案。主要是考慮到更加直觀和友好，而且方便版本回退。

7. 上線發(fā)布流程

對(duì)于開(kāi)發(fā) 測(cè)試以及線上環(huán)境，靜態(tài)資源都是共享的，所謂上線，只不過(guò)是將對(duì)于環(huán)境下的版本更新下而已。后端同學(xué)提供了導(dǎo)入導(dǎo)出工具，方便組件的發(fā)布上線。

8. CI持續(xù)化集成

每個(gè)組件都對(duì)應(yīng)獨(dú)立的前端項(xiàng)目，我們?yōu)檫@些項(xiàng)目接入CI服務(wù)，并將組件的構(gòu)建，版本發(fā)布以及靜態(tài)資源發(fā)布等等集成在CI任務(wù)中，另外，為了方便進(jìn)行組件的性能優(yōu)化，我們借助webpack 插件為每次構(gòu)建都生成一份構(gòu)建報(bào)告：

基礎(chǔ)庫(kù)管理

首先所面臉的問(wèn)題：在我們的設(shè)計(jì)中，PM的每個(gè)組件的都是獨(dú)立的，單獨(dú)構(gòu)建的。因?yàn)榻M件開(kāi)發(fā)都需要依賴(lài)React，如果在構(gòu)建時(shí)將React構(gòu)建進(jìn)去，那么運(yùn)行態(tài)下就會(huì)存在多份react，而react是不允許多實(shí)例共存的，所以這就產(chǎn)生了問(wèn)題。除了react，還可能依賴(lài)其他一些比較大的類(lèi)庫(kù) 比如recharts。

關(guān)于這個(gè)問(wèn)題，我們最開(kāi)始采用的方案是 webpack dll。一切看起來(lái)都是那么完美，直到我們?cè)谏?jí)react 16 的過(guò)程中，痛苦出來(lái)了。因?yàn)閞eact升級(jí)，所以我們要構(gòu)建出新的dll來(lái)，dll更新了，那么原來(lái)那些發(fā)布過(guò)的組件，都需要基于新的dll重新構(gòu)建一遍，才能在運(yùn)行態(tài)下正常渲染。OMG，工作量太大了，而且涉及到多個(gè)業(yè)務(wù)線下的上百個(gè)組件。問(wèn)題已經(jīng)比較嚴(yán)重了。

經(jīng)過(guò)商量，我們最終用webpack external 代替了 dll的方案，雖然dll在運(yùn)行態(tài)下的性能會(huì)稍好一些，但是所帶來(lái)的問(wèn)題已經(jīng)遠(yuǎn)遠(yuǎn)超過(guò)收益了。

運(yùn)行態(tài)資源加載與性能優(yōu)化

前面提到PageMak是一個(gè)平臺(tái)，各個(gè)業(yè)務(wù)方都會(huì)在這個(gè)平臺(tái)上開(kāi)發(fā)和發(fā)布組件，然后在運(yùn)行態(tài)下統(tǒng)一加載和渲染。那該怎么加載 加載哪些，才能達(dá)到更好的頁(yè)面加載性能，就是一個(gè)很值得研究的話題。 關(guān)于這個(gè)問(wèn)題的方案，其實(shí)演變了很多。

野蠻時(shí)代

剛開(kāi)始的時(shí)候，按照我們的設(shè)計(jì)，每個(gè)業(yè)務(wù)線都有一個(gè)前端項(xiàng)目，這個(gè)項(xiàng)目下維護(hù)著該業(yè)務(wù)線下的所有組件，也就是說(shuō)，所有的的組件都會(huì)打包在一起，單個(gè)組件沒(méi)有獨(dú)立的版本控制。所以，順利成章的，這種情況下，我們?cè)谶\(yùn)行態(tài)就按照業(yè)務(wù)線來(lái)加載組件，如果當(dāng)前的租戶開(kāi)通了應(yīng)用，那么，就會(huì)去加載這個(gè)組件。這也是最初的設(shè)計(jì)，后來(lái)做了一點(diǎn)點(diǎn)的優(yōu)化，就是判斷下，如果當(dāng)前的頁(yè)面上拖入了某業(yè)務(wù)線下的組件，才會(huì)加載這個(gè)業(yè)務(wù)的組件。這里的判斷邏輯由后端同學(xué)實(shí)現(xiàn)。，前端只負(fù)責(zé)加載和渲染。

工業(yè)社會(huì)

后來(lái)，隨著業(yè)務(wù)線組件的增加，這個(gè)項(xiàng)目變得越來(lái)越龐大，如果某個(gè)頁(yè)面上只拖入了業(yè)務(wù)線下的一個(gè)組件，那么該業(yè)務(wù)線下的所有組件都會(huì)加載進(jìn)來(lái)。而且更嚴(yán)重的是上面提到的，單個(gè)組件沒(méi)有的獨(dú)立的版本控制，這其實(shí)是很要命的。所以為了解決這個(gè)問(wèn)題，經(jīng)過(guò)商量過(guò)后，我們決定將單個(gè)組件拆分為獨(dú)立的前端項(xiàng)目?；诖耍覀?cè)谶\(yùn)行態(tài)下資源加載的顆粒度，就可以控制到組件級(jí)別的了。

也就是說(shuō)，我們通過(guò)元數(shù)據(jù)分析，可以得知該頁(yè)面上拖入了哪些組件， 以及組件的版本。然后，加載模塊就會(huì)將所有的組件通過(guò)異步腳本的方式加載進(jìn)來(lái)，交給渲染器去渲染。（至于渲染器如何知道哪些組件加載進(jìn)來(lái)了，哪些組件沒(méi)有加載進(jìn)來(lái)，這是通過(guò)一個(gè)組件的注冊(cè)模塊來(lái)實(shí)現(xiàn)的。）

方案走到這里，已經(jīng)將所有的冗余的資源都去掉了，看似很完美，但其實(shí)還是有問(wèn)題的。

首先，一個(gè)頁(yè)面上可能會(huì)拖入很多組件，少則七八個(gè)，多則一二十個(gè)，每個(gè)組件都對(duì)應(yīng)一個(gè)js資源，那么要想頁(yè)面渲染出來(lái)，至少將這些js腳本全部加載完成。但是，客戶端對(duì)于并行請(qǐng)求數(shù)是有限制的，沒(méi)記錯(cuò)的話應(yīng)該是5個(gè)，從這方面考慮的話，前端性能優(yōu)化的一個(gè)很重要的方向就是資源合并，比如常見(jiàn)的雪碧圖。