Page Maker是我在公司參與時間最長的一個項目了，自打實習期做了webIM，轉正之后不久，就開始參與了PageBuilder項目的開發，前前后后大概經歷了兩年的時間，后來由于公司業務調整，已經在今年初逐步將項目交接了出去。雖然現在不再參與項目的維護，但是從這么長時間的開發過程中，還是學到了很多東西，也讓我成長了很多。其實最關鍵的，并不是具體解決了什么問題，而是解決問題的思路與方法。

PM 的產品定位是一個平臺，他所提供的核心能力就是頁面的可視化構建，通過拖拖拽拽，就可以生成一個頁面，并所見即所得。為公司的各產品先以及后續的ISV提供穩定 可靠 自由的頁面定制化能力，以此滿足客戶的多樣化需求。

在實際的開發過程中，我們遇到以及需要解決的問題有：

(相關資料圖)

組件化元數據結構設計組件開發規范運行態資源加載與性能優化基礎依賴管理

其實每個點都能單獨寫一篇文章的，這里就只簡單總結了。

組件化

在PM的實現中，頁面組件化是一個非常重要的前提，所以我們抽象出了兩個概念，即：

布局組件視圖組件

布局組件用以實現頁面布局，而視圖組件承載著業務數據，并以多樣化的形式展現給用戶。所以頁面長得好不好看，直接取決于視圖組件。 另外，為了提高視圖組件的可擴展性，以及凸顯PM所強調的 可配置的能力，我們還抽象出了一個組件類型，即 屬性組件。

有了屬性組件，實施人員就可以給視圖組件配置不同的屬性，比如數據源，展示形式，等等，對于視圖組件來說，所有可變，可配置的，都以通過屬性組件來實現。通過 PM平臺，將屬性組件和視圖關聯展示到頁面上，并最終呈現給用戶。

元數據結構設計

基于元數據的應用設計的最大的好處就是可描述和可擴展。我們將頁面抽像為一套元數據結構，而pb就是這套元數據的解析器。保存頁面，實質上就是保存了一份元數據的實例。

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

組件開發規范

在這個問題下，細分的問題還是挺多的比如：

1. 技術選型

這個其實沒有太多可說的，公司整個平臺都采取的React框架，所以為了保持統一，當然就是直接采用React

2. 組件開發模版

這里的模版設計所遵循的原則應該是盡量簡潔，符合常規的開發習慣，并將細節封裝好隱藏在內部。我們會提供一條龍的服務，包括但不限于構建方案 組件注冊 以及對接CI服務，對于業務方來講，只需要關注于組件的開發即可。另外，模版設計時，一定要遵循模塊化 分層設計的思想，盡量減少后續模塊升級所帶來的遷移成本。

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

4. cli工具

前端工程化設計中，一個很重要的原則就是自動化，將所有重復性的，工程化的工作，交給程序完成，從而盡可能的提升工作效率。所以我們開發cli工具，將組件注冊 git項目搭建，以及生成本地開發模版的任務全部集成在cli工具中，開發人員一分鐘的時間，就可以開始新組件的開發

5.css 模塊化

相對于JS的發展的來講，CSS的進度確實緩慢了些。因為PM頁面上的組件都是獨立構建的，但是會放在同一個運行態下，所以很容易出現樣式覆蓋的問題。為了保持樣式的穩定，作為平臺，必須提供統一的css 模塊化方案。經過技術方案的調研和對比，最終采取了styled-component。至于為什么不采用css module，是因為他的hash是在構建過程完成計算的，而不是運行時，所以不能從根本上解決PM平臺所面臨的問題。

6. 版本管理

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

7. 上線發布流程

對于開發 測試以及線上環境，靜態資源都是共享的，所謂上線，只不過是將對于環境下的版本更新下而已。后端同學提供了導入導出工具，方便組件的發布上線。

8. CI持續化集成

每個組件都對應獨立的前端項目，我們為這些項目接入CI服務，并將組件的構建，版本發布以及靜態資源發布等等集成在CI任務中，另外，為了方便進行組件的性能優化，我們借助webpack 插件為每次構建都生成一份構建報告：

基礎庫管理

首先所面臉的問題：在我們的設計中，PM的每個組件的都是獨立的，單獨構建的。因為組件開發都需要依賴React，如果在構建時將React構建進去，那么運行態下就會存在多份react，而react是不允許多實例共存的，所以這就產生了問題。除了react，還可能依賴其他一些比較大的類庫 比如recharts。

關于這個問題，我們最開始采用的方案是 webpack dll。一切看起來都是那么完美，直到我們在升級react 16 的過程中，痛苦出來了。因為react升級，所以我們要構建出新的dll來，dll更新了，那么原來那些發布過的組件，都需要基于新的dll重新構建一遍，才能在運行態下正常渲染。OMG，工作量太大了，而且涉及到多個業務線下的上百個組件。問題已經比較嚴重了。

經過商量，我們最終用webpack external 代替了 dll的方案，雖然dll在運行態下的性能會稍好一些，但是所帶來的問題已經遠遠超過收益了。

運行態資源加載與性能優化

前面提到PageMak是一個平臺，各個業務方都會在這個平臺上開發和發布組件，然后在運行態下統一加載和渲染。那該怎么加載 加載哪些，才能達到更好的頁面加載性能，就是一個很值得研究的話題。 關于這個問題的方案，其實演變了很多。

野蠻時代

剛開始的時候，按照我們的設計，每個業務線都有一個前端項目，這個項目下維護著該業務線下的所有組件，也就是說，所有的的組件都會打包在一起，單個組件沒有獨立的版本控制。所以，順利成章的，這種情況下，我們在運行態就按照業務線來加載組件，如果當前的租戶開通了應用，那么，就會去加載這個組件。這也是最初的設計，后來做了一點點的優化，就是判斷下，如果當前的頁面上拖入了某業務線下的組件，才會加載這個業務的組件。這里的判斷邏輯由后端同學實現。，前端只負責加載和渲染。

工業社會

后來，隨著業務線組件的增加，這個項目變得越來越龐大，如果某個頁面上只拖入了業務線下的一個組件，那么該業務線下的所有組件都會加載進來。而且更嚴重的是上面提到的，單個組件沒有的獨立的版本控制，這其實是很要命的。所以為了解決這個問題，經過商量過后，我們決定將單個組件拆分為獨立的前端項目?；诖?，我們在運行態下資源加載的顆粒度，就可以控制到組件級別的了。

也就是說，我們通過元數據分析，可以得知該頁面上拖入了哪些組件， 以及組件的版本。然后，加載模塊就會將所有的組件通過異步腳本的方式加載進來，交給渲染器去渲染。（至于渲染器如何知道哪些組件加載進來了，哪些組件沒有加載進來，這是通過一個組件的注冊模塊來實現的。）

方案走到這里，已經將所有的冗余的資源都去掉了，看似很完美，但其實還是有問題的。

首先，一個頁面上可能會拖入很多組件，少則七八個，多則一二十個，每個組件都對應一個js資源，那么要想頁面渲染出來，至少將這些js腳本全部加載完成。但是，客戶端對于并行請求數是有限制的，沒記錯的話應該是5個，從這方面考慮的話，前端性能優化的一個很重要的方向就是資源合并，比如常見的雪碧圖。