沪江前端由H5页面引起的一场前端数据结构讨论

类型

内容

位置

大小

颜色

背景图

链接

其他特征

</>复制代码 
元素: {
    类型,
    内容,
    位置,
    大小,
    ...
}

元素上的属性比较庞大，但还是可以放在一个元素的对象里。设想如果把这些部分也放在该元素的数据结构上，不单单有内容数据，还有样式上的数据，属性上的数据等等，这样是否就可以渲染了。那么目标有新增，如何去编辑这“庞大”的属性集合。

我们假设一段需要的带属性样式的元素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，但从数据结构的设计形式上看，本质上变化其实并不是很大，只是