设计器技术方案
xinglie opened this issue · comments
分
分而治之的思路在各行各业都可以看到，设计器里也不例外。
在设计器里所有的一切都是分而独立的，比如头部元素栏、工具栏、标尺等。大到面板，小到可被设计的元素均是互相隔离且独立的，彼此之间不知道对方存在。理论上设计器中只要被拆分的界面均可以渲染到其它页面的任意位置上，这为调整软件界面布局提供了很大的便利。
分的思路也为我们插件化的工程打下了良好的基础，当某些功能不需要或添加新功能时，只需要简单的删除或增加相应的代码即可。在设计器中，所有的一切均为插件化，包括基础的工具栏、标尺、右键菜单等，这些仅是设计器中数据状态的一个展示层，不与设计器核心代码偶合
设计器中的核心模块也是采用分的思路进行开发，历史记录、剪切板、元素操作、吸附对齐、选区、快捷键等均为互相独立的模块，这些模块所有的操作都是控制内存中的数据描述，即使没有界面一样可以完成数据的修改变换。当然，界面的存在仅是对这份数据描述进行可视化展示，实时反映内存中数据的状态和对应的可操作项，便于向用户反馈和方便数据修改。
合
大的组织还是需要独立的单元互相合作来完成更复杂的事情
项目中所有父到子的传递均由参数直接控制，即子提供控制参数，在父级进行传参控制。所有子到父的传递均是标准的DOM事件派发，这样更利于与第三方进行合作，只需要把设计器中的元素当成标准的HTML标签即可，所有事件均可以通过标准的addEventListener及removeEventListener进行添加和移除
所有需要联动的元素均由中介者进行控制，元素各自仍是互相独立的，通讯控制则交与中介进行管理，这样在不引入中介时，彼此不会联动，引入中介时，由中介控制它们进行联动。中介模块也是插件化的存在。
界面与数据
基础数据是用于描述设计区大小、颜色以及包含哪些元素，这些元素在什么样的位置上等基本信息，当我们点击保存时，保存的就是这份数据。
在基础数据上面，是经过业务需求计算处理后的逻辑数据层，比如选中的元素能不能克隆、复制等，选中的容器格子能否合并或拆分，这些数据均为逻辑控制数据。设计器中会提供大量这样的API对基础数据进行处理封装，方便我们对基础数据的展示和处理。
到这一步不需要界面，只需要API即可完成对基础数据的读取和修改。
界面仅是对逻辑数据可视化的一种方式，让用户可以通过界面直观的经过逻辑处理层修改这份数据，同样，即使没有界面，也可以通过逻辑控制层提供的API完成对基础数据的操作。
这种设计方式可以让我们更好的任意更换界面和提供数据修改控制、调度，按自己的喜好向用户提供设计器的功能
支持任意需求
设计器中的被设计元素是插件化的存在，设计器抽象了通用的可视化拖动、对齐、复制、粘贴等通用功能，可适用不同的元素可视化的操作。
目前设计器自带了近百种元素，这些元素大多数是为了验证设计器的能力而存在的。
现实需求是多种多样的，而且类似的需求从不同的角度可视化设计，带给使用者的便利程度也不同。通用设计器为了更贴近使用者，抽象出了各种元素来适应不同的可视化需求，避免使用同一个类型的元素，增加巨多的配置让使用者无从下手。