類型

內容

位置

大小

顏色

背景圖

鏈接

其他特征

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

元素上的屬性比較龐大，但還是可以放在一個元素的對象里。設想如果把這些部分也放在該元素的數據結構上，不單單有內容數據，還有樣式上的數據，屬性上的數據等等，這樣是否就可以渲染了。那么目標有新增，如何去編輯這“龐大”的屬性集合。

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

    

        content"s context
    

相比“小例子”中的

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 結構大致如下：

    

    

    ...

再把一個個單頁拼起來，就變成了我們需要的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，但從數據結構的設計形式上看，本質上變化其實并不是很大，只是