作者：周周（沪江资深Web前端开发工程师）本文为原创文章，转载请注明作者及出处转载之际，看到了梦工厂自家H5主题生成的页面。与小D的十年回忆>>回忆一件往事，现在看还蛮有意思??的。主要是一个逐渐将业务抽象成数据的过程，对当时对数据设计还不太敏感的自己有很大的提升。所以想通过这篇文章分享一些关于如何构建可视化编辑页面系统的开发设计思路。也希望对前端小伙伴在构建类似的中大型应用时有所帮助，可以更好的设计一些更复杂的数据结构。本文不会贴出具体的实现代码，更多的是讲一下为什么这样设计背后的思考过程，以及一些业务是如何映射到数据上的。如有不足之处，请轻拍。先预览一下编辑器的后台界面。编辑小伙伴可以像在桌面应用中一样操作，最后直接生成一个h5页面。背景当时2014年是H5比较火的时期，很多时候在业务中会遇到一些重复、雷同的H5活动页面，而且开发差不多要变成ctrl+c和ctrl+v，有点无聊。后来出现了很多h5页面编辑应用，比如某秀，某KA等。有一天，可爱的老板又从后面看了我们一眼，突然说：我们也做一个吧？当时的反应是，万匹草泥马从我头上碾过：这个有点太复杂了，成本太高了，还是不做吧。但是静下心来想着做完了可以解放一批开发同学。挑战不小，所以我想为什么不呢？于是开始了构建可视化编辑页面系统WebIDE的旅程。从计划开始的那一刻起，脑子里其实一片空白。在做了一些小demo之后，我开始有了一些想法，这不是一蹴而就的。举个小例子**场景：前后端协同，需求是在页面添加一个异步请求列表模块。1.发送请求并处理数据。接口响应返回的数据可能是：{...,data:{list:[{id:1,content:'这是第一条数据'},{id:2,content:'这是第第二条数据'},{id:3,content:'这是第三条数据'}],total:4}}2.根据列表中的数据，循环出要渲染的DOM结构
1。这是第一条数据2。这是第二条数据3.这是第三条数据3。找到需要添加或替换的节点，然后添加到页面上。在上面的场景中，这种数据结构可能是最常遇到的。整个过程可以理解为先获取数据，然后将数据转化为渲染视图。纵观目前流行的框架，react、vue等都帮助我们省去了关注DOM的步骤。这里我们抛开一些框架的方便，回归到最初的步骤，由一个renderer方法来完成。+--------++----------++------+|数据|=>|渲染器|=>|DOM|+--------++---------++------+小伙伴要问了，这个过程比较熟悉，但是如果你做一个WebIDE，不就那么几步吧？需求分析怎么写，需要详细写。写的时候发现题目变复杂了。大多数时候它看起来像下图。然后放轻松，试着把它拆成一些小零件进行分析。多观察，多联想，多分析。制定目标如何将H5页面转换为可编辑状态。状态分析观察一个普通的H5活动页面，先尝试提取几个关键元素。尝试滑动页面。你可以大致猜到这是一个占满屏幕的滑动组件。交互分为上下滑动，可能有回调等。这时候你会发现一个H5上可能有一个或多个子页面（分页），可能会涉及到分页操作。再看每个页面，都有一些图片、链接、文字等元素，显示形式大不相同，风格也不一样。似乎很难统一。放手吧。但是两个关键点出现了，分页+元素。一个h5页面基本上是由很多页面和元素组成的。目标将转化为如何编辑分页和如何编辑元素。详细分析，单独看一个页面，详细分析：可以发现页面中有很多元素，大致有：图片、音频、视频、文字、内容、链接、动画等元素。尝试抽象一层，一个页面可能变成如下结构：page:[Element1,Element2,Element3]发现结构有点类似于“小例子”，一个块包含多个子块，按照类似的渲染方式，估计页面上也可以渲染元素，但是样式不同，元素之间的差异比较大，类型也不同。你想如何将列表拼接在一起？试对比一下，上面“小例子”中的列表数据包含了部分内容数据。如果把
看成是一个元素，那么这些元素的类型都是一样的，data就是元素内容。其他一些属性或事件如样式是在其他地方定义的，不在这个数据结构中。我们回到元素本身来观察，它是如何抽象出来的，它有什么特点呢？typecontentpositionsizecolorbackgroundimagelinkothercharacteristicelements:{type,content,position,size,...}元素上的属性比较大，但是还是可以放在一个元素对象中。想象一下，如果这些部分也放在元素的数据结构上，不仅是内容数据，还有样式上的数据，属性上的数据等等，这样就可以渲染出来了。那么目标已经添加，如何编辑这个“庞大”的属性集合。通过反复试验，我们假设元素的必需DOM结构具有属性样式：content'scontext 