滬江前端由H5頁面引發的一場前端數據結構討論

做者：週週（滬江資深Web前端開發工程師） 本文爲原創文章，轉載請註明做者及出處

前言

近期在小D十週年活動之際，又看到了一個自家H5專題夢工廠生成的頁面。

我與小D十年回憶 >>

回想起了一段往事，如今來看還蠻有趣的。主要是一個將業務逐步抽象成數據的過程，對於當時對數據設計等還不太敏感的本身有不小的促進做用。因而想經過本文分享下當初如何搭建可視化編輯頁面系統中的一些開發設計思路，也但願對前端夥伴們在構建相似中大型應用時有必定幫助，能夠更好地設計一些較複雜的數據結構。本文不會把具體的實現代碼貼出來，更多的是背後爲什麼要這樣設計的一些思考過程，如何把一些業務映射到數據。有不足之處，還請輕拍。

讓咱們一塊兒先來預覽下編輯器的後臺界面，編輯夥伴能夠像在桌面應用中同樣進行操做，最後直接生成一個h5頁面。

背景

當時14年正值H5比較火熱的時期，業務中不少時候會碰到一些重複相似的h5活動頁面，開發幾乎要變成 ctrl+c 和 ctrl+v 了，略顯枯燥。後來涌現出了不少h5頁面編輯應用，某秀、某KA等。某一天可愛的老大又在背後看着咱們，忽然來了一句：

咱們要不也搞一個？

當時反應是萬匹草泥馬在頭上奔過: 這個有點太複雜了，成本過高，仍是不作了吧。不過冷靜下來後，心想作完還能夠解放一批開發同窗，挑戰也不小，因此心想

爲何不呢？

因而就開始了一個可視化編輯頁面系統 Web IDE 的打造之旅。從計劃開始作的那一刻起，實際上是腦中一片空白，後來作了一些小DEMO後，纔開始有了點思緒，也不是一蹴而就的。

先舉個小例子**

場景: 先後端協做，需求是在頁面上加一個異步請求的列表模塊。

1.發送請求，處理數據。接口響應回來的數據多是：

{
    ...,
    data: {
        list: [
            {id: 1, content: '這是第一條數據'},
            {id: 2, content: '這是第二條數據'},
            {id: 3, content: '這是第三條數據'}
        ],
        total: 4
    }
}
複製代碼

2.根據 list 中的數據，循環拼接出須要渲染的DOM結構

<li>1.這是第一條數據</li>
<li>2.這是第二條數據</li>
<li>3.這是第三條數據</li>
複製代碼

3.找到須要追加或者替換的節點，而後加到頁面上。

在上面這個場景中，這類數據的結構多是最常碰到的。整個過程能夠理解爲，先獲取數據，再把數據轉換到渲染視圖裏。看目前流行的框架，react，vue 等都幫咱們省略了關注 DOM 的步驟，在這裏咱們先拋開一些框架的便利，迴歸到原始的步驟，由一個 renderer 方法充當。

+--------+      +----------+      +-------+
|  data  |  =>  | renderer |  =>  |  DOM  |
+--------+      +----------+      +-------+
複製代碼

夥伴要問了，這個流程比較熟悉，但若是作一個 Web IDE 不是就這麼幾步吧？

如何下筆

需求分析要詳細

要下筆時，發現課題變得複雜了。不少時候就會像下面這張圖中。

那先緩一緩，先嚐試着拆解成一些小部件來分析。多觀察，多聯想，多分析。

制定目標

如何把一個H5頁面轉換成一個可編輯的狀態。

現狀分析

觀察一個普通的H5活動頁面，試着先抽取幾個關鍵元素。試着滑動頁面，大體能夠猜想這是一個滑動組件，佔滿全屏的，交互能夠劃分爲上下滑動，可能還有回調等等，這時能夠發現一個H5上可能有一個或多個子頁面（分頁），這裏面可能將會涉及到分頁的操做。再看每一個分頁上，有圖片，連接，文字等等一些元素，展示形式差別很大，樣式都不同，看起來很難統一，不像上面的小例子中能夠比較容易地拼湊出，先放一放。可是有兩個關鍵點浮現出來了，分頁+元素，一個h5頁面基本都是由不少頁面和元素組成的，目標將轉換成如何編輯分頁，如何編輯元素。

詳細分析

再單獨看一個頁面詳細地分析下：

能夠發現頁面中有不少元素，大體有：

• 圖片
• 音頻
• 視頻
• 文字內容
• 連接
• 動畫
• 其餘元素們

試着抽象一層，一個頁面可能會變成下面的結構：

頁面: [
    元素1,
    元素2,
    元素3
]
複製代碼

發現和「小例子」中的結構有點相似，一個塊包含多個子塊，照着相似的渲染方式，估計也能將元素們渲染到頁面上，但樣式卻各不同，元素之間的差別比較大，類型又不一樣，怎麼想拼接 list 列表同樣拼呢？試着比較下，上面「小例子」中的列表數據包含的是偏內容的數據，把 <li> 當作一個元素的話，分析下，這些元素的類型是同樣的，數據裏包含的是元素內容，而樣式等一些其餘屬性或事件都是定義在了其餘地方，並不在這個數據結構裏。再回到元素自己上觀察下，如何抽象，有哪些特徵？

• 類型

• 內容

• 位置

• 大小

• 顏色

• 背景圖

• 連接

• 其餘特徵

  元素: { 類型, 內容, 位置, 大小, ... }

元素上的屬性比較龐大，但仍是能夠放在一個元素的對象裏。設想若是把這些部分也放在該元素的數據結構上，不僅僅有內容數據，還有樣式上的數據，屬性上的數據等等，這樣是否就能夠渲染了。那麼目標有新增，如何去編輯這「龐大」的屬性集合。

試錯

咱們假設一段須要的帶屬性樣式的元素DOM結構：

<div class="element someClass" style="someKeyA: someValueA;someKeyB: someValueB;" data-custom="someCustomData">
    <div class="content">
        content's context
    </div>
</div>
複製代碼

相比「小例子」中的 <li> 多了不少屬性和結構，根據上面的 DOM 結構，用對象的形式抽象下，格式大體以下：

element: {
    style: {
        someKeyA: 'someValueA',
        someKeyB: 'someValueB',
    },
    class: ['someClass'],
    attribute: {
        custom: 'someCustomData',
    },
    content: {
        text: 'content\'s context'
    }
}
複製代碼

這樣的話，咱們就能夠經過一個拼接方法來生成咱們想要的結構。這樣一個關於元素的數據結構設計就有了雛形。咱們能夠經過修改元素上一些屬性的值，改變元素的外在表現。整個過程能夠簡化成數據的變化引發視圖的變化，和如今不少前端框架數據驅動思想有幾分類似。

整理

經過相似上面不少小 demo 的積累，最後能夠整理拼裝下，回到單個頁面上，除了元素，可能還有一些其餘設置，假想預留一些字段。

那麼一個頁面抽象下，格式大體以下：

page: {
    elements: [
        {
            style: ...,
            class: ...,
            attribute: ...,
            content: ...,
        },
        { element2 },
        { element3 },
        { element4 },
        { element5 },
    ],
    setting: {
        propertyA: {},
        propertyB: 'valueB',
        flagC: false,
    }
}
複製代碼

生成的 DOM 結構大體以下：

<div class="page" data-flagC="false" ...>
    <div class="element element1" ...></div>
    <div class="element element2" ...></div>
    ...
</div>
複製代碼

再把一個個單頁拼起來，就變成了咱們須要的H5頁面，格式大體以下：

h5: {
    pages: [
        {
            elements: ...,
            setting: ...,
        },
        {page2},
        {page3},
        {page4},
    ],
    setting: {
        propertyA: {},
        propertyB: 'valueB',
        flagC: false,
    }
}
複製代碼

從一個個小元素組成一個頁面，再由一個個頁面組成h5活動頁面。至此一個對於h5頁面的抽象出來的數據結構雛形基本完成了。

上面的結構沒有展開，展開後你會發現這個大對象可能上千上萬行，接下來關注下數據和操做界面中的映射關係了，如何去操做這些數據，數據怎麼展示，元素和頁面的關係等等。

業務映射到數據

爲什麼要操做數據，而不是去操做DOM？

這也是在前期開發中踩過的坑，照着「所見即所得」的模式，像富文本編輯器同樣，輸入修改完就是最終輸出的內容，也何嘗不可，實現時習慣使用 jQuery 的夥伴很容易會聯想到直接操做 DOM，好比一個元素的定位，使用 jquery-ui 的 draggble 拖拖拽拽很方便的定位，最後產出的就是最後實際的HTML。但放在實際場景中後，會發現拓展性兼容性不太友好。特別是在後期再去操做一段成品的 DOM 結構會變得比較麻煩，好比一個定位的數據，成品中的數據會看起來比較「死」，在適配不一樣屏幕時，計算對應的值會比較累。而若是是操做數據的話，能夠在渲染以前對數據進行些處理，最後的產出就變得比較靈活，將數據層和視圖層抽離的比較獨立，拓展起來也比較容易。

映射關係

如何把這些界面的業務抽象成數據操做，首先仍是簡單分析整理下。一個可視化編輯應用的操做有不少，這裏只舉幾個類型的數據操做。用戶經過操做（好比輸入、拖拽、移動、點擊等）來改變元素的屬性值。

用腦圖發散一下有哪些功能：

• 頁面的增刪改查
• 元素的增刪改查
• 歷史記錄的操做
• 用戶操做
• 其餘

讓咱們回到已經制定的目標上，如何編輯頁面，如何編輯元素。下面舉幾個例子

頁面編輯 一個H5由多個頁面組成，由幾個{元素}組成的[元素集合]，此類關係一般能夠用數組來表示。

將頁面集合簡單成抽象成數據的操做：

+-------------+
    |             |
    +-------------+

    => pages: [], index: -1
複製代碼

新增頁面時，在 pages 數組中 push 一個'page 1'的實例對象，再經過索引取到該實例數據, 而後經過渲染方法將對應的視圖渲染到界面中，這個關係鏈就基本完成了。

+-------------+
    |    page 1   |
    +-------------+

    => pages: [ page1 ], index: 0
複製代碼

交換頁面順序

+-------------+
    |    page 2   |
    +-------------+
    |    page 1   |
    +-------------+

    => pages: [ page2, page1 ], index: 1
複製代碼

經過數組的兩個值的順序交換便可以實現兩個頁面的順序交換，發現不少場景只須要經過一些數組最基本的操做就能夠實現一些看起來複雜的功能，而困難的更可能是如何找到這一層映射的關係。

元素操做

元素有多種屬性組成，多個{屬性鍵值對}組成的{元素}，此類關係一般能夠用對象鍵值對來表示。

在元素對象上不斷拓展須要變化的屬性，好比元素的尺寸位置：

element: {
    style: {
        'top',
        'left',
        'width',
        'height',
    },
    ...
}
複製代碼

能夠設計如上圖四個輸入框，每一個輸入框對應每個屬性值，這樣一個簡單的元素屬性編輯控件就行了，依次類推，每加一個可編輯屬性就對應加一個編輯控件。基本上都是以key-value的形式來操做。整個過程簡化成用戶經過界面的輸入修改操做數據，數據更改後視圖對應從新渲染一遍。

根據不斷的嘗試和增長，最後結構變成了相似以下的格式：

element: {
    id: 1,
    role: {
        type,
        value
    },
    style: {
        'top',
        'left',
        'width',
        'height',
        'transform',
        ...
    },
    inner: {
        html: 'rich text',
        style:{
            'background-image',
            'background-color',
            'background-size',
            'opacity',
            'color',
            'font-size',
            'text-align',
            'border-radius',
            ...
        }
    },
    attribute:{
        'animation-sequence',
    }
}

+--------+--------+----------+---------+-------------+
|  id    |  role  |  style   |  inner  |  attribute  |
+--------+--------+----------+---------+-------------+
|   1    |  link  |    ...   |   ...   |     ...     |
+--------+--------+----------+---------+-------------+
|   2    |  text  |    ...   |   ...   |     ...     |
+--------+--------+----------+---------+-------------+
複製代碼

完善後，一個元素的結構已經變得相對龐大了，包含了很是多的屬性，隨之而來的也是很是多對應的屬性編輯控件，也是相對比較複雜的地方。

歷史操做

怎麼抽象設計？這在平時業務場景裏並很少。先分析下歷史要什麼？主要就是撤銷和恢復，用戶能夠 ctrl+z 回到上一個狀態。歷史這個大集合裏確定有多個歷史狀態，由多個{歷史}組成[歷史集合]，因而就想到了數組。新狀態和老狀態的區別是什麼？可能就是有了新的操做，數據有了變化，那麼把這時的數據保存起來，塞到歷史裏，至關因而一個 push 的操做，看起來可行。再假如須要回到上一個狀態，能夠設置個索引 index, 將 index 指向到前一個，就拿到了前一個狀態。

| -- push
            +------v------+
  index --> |   status 3  |
            +-------------+
            |   status 2  |
            +-------------+
            |   status 1  |
            +------|------+
                   v -- shift
複製代碼

抽取幾個關鍵點:

- 有多個狀態        -> 數組
- 不一樣狀態之間指向   -> 數組的索引值, 遊標
- 能夠作個步數限制   -> 數組的長度
複製代碼

場景：有一個新的操做，即將新的數據插入到歷史中

history.push(statusNew);
複製代碼

場景：若是滿了，將最早插入的數據拿出來

history.shift();
複製代碼

場景：撤銷一步，將遊標指向到前一個，取到前一個狀態。重作一步同理。根據這時的數據從新渲染，那麼界面上也就回到了前一步的狀態。

cursor --;
callback(history[cursor]);
複製代碼

那麼history的結構就可能長成以下:

[
    {status1},
    {status2},
    {status3},
    {statusNew},
]
複製代碼

這樣一個簡單的歷史數據結構設計就完成了。

留個問題: 若是撤回到了上幾步，而後繼續操做，整個歷史狀態該怎麼處理？

最後

最後再經過組裝整合，一個可視化編輯器主要的功能大體就知足了。再從新看下操做界面上的數據，能夠劃分爲兩個部分，一個前臺頁面數據，一個後臺交互數據，大體以下：

回顧上面的過程，已經從一個簡單的數據列表渲染到具備先後臺複雜型數據交互的WebIDE，但從數據結構的設計形式上看，本質上變化其實並非很大，只是<li>變成了<element>,<page>等，裏面包含的數據量也增長了許多。會不會發現這個數據雖然看起來十分龐大複雜，但也有幾分清晰簡單。而你的角色更像是一位建築設計師，把握整個結構框架，而後再管理一磚一瓦。

上述的過程在開發其餘項目時一樣適用，在開始設計時，要一會兒腦補出整個設計是比較困難的，特別是對某一個事物從一無所知到有點概念，從0到1的過程，客觀的說這並不容易。能夠先試着抽離出幾個關鍵步驟，寫幾個小模塊，把關鍵路徑走通，在初期十分有效，隨後再這些看似零散的小組件拼裝起來，每每這個雛形會比一開始想的清晰不少，如此反覆，整個設計也會變得更加清晰飽滿。數據的設計也是相對應的，由一個個小的數據組成，漸漸的便會造成一個比較龐大的數據，這時代碼可能不是最關鍵的，而是如何合理有效清晰地管理這些數據，可能更像是後端數據庫管理同樣。每每須要通過不斷的試錯走些歪路的過程，最後會慢慢駕輕就熟一點。好設計是不斷迭代出來的，勇敢試錯，不怕踩坑，有句話叫，坑踩的深才銘心刻骨。

iKcamp原創新書《移動Web前端高效開發實戰》已在亞馬遜、京東、噹噹開售。

iKcamp新課程推出啦～～～～～開始免費連載啦～每週２更共11堂iKcamp課｜基於Koa2搭建Node.js實戰項目教學（含視頻）| 課程大綱介紹