关于组件编辑器的一些思考 #

当下工作流程我认为是相对传统的工作方式，即设计师在设计平台上先做好图，前端切图仔再将其用前端语言实现，完成后设计师还需要 check 是否与图一致，在技术日新月异的今天，还有提效的空间。

组件编辑器的核心思想，设计即生成代码，直接被页面消费，还可以直接发布到私有组件仓库。

理想情况下，设计师在组件中心设计编排该项目相关组件后，再拼接组装到页面，这一步，即完成了组件的静态实现，在编排的过程中，标记好哪些静态数据是需要传值的。接下来交给培训过的专员设定组件接受数据的类型，单一数据对象或循环数据，相应的需要设定组件的数据模型，并定义好字段名和类型。

实际上，设计师在 sketch 上作图，导出标注图到蓝湖，平台不同的历史积累或跨行业的术业专攻，这一点将很难改变。

现实情况下，我们依旧可以优化这一工作方式，培训过的专员将设计图中的某个组件截图导入到组件编辑器，即基本完成了组件的静态实现——布局和样式。再不济，结合组件中心已有物料通过简单的拖拉拽精确还原。

这样的结果下，会触使人思考这样一个问题：和本地开发的区别在哪？
拖拉拽对应本地写div，数据模型对应写数据赋值，组件复用沉淀本地同样可以做......

回过头来再看看最初的想法，想要提效是第一目标，由于种种原因导致中间环节无法实现而被迫降低了要求后，仍然可以曲线救国。需要承认的是，在上述思想下，和本地开发确实无异，但是，如果组件的颗粒度大一些呢，页面的含义再垂直一些呢？换句话说，和本地编码似得颗粒度细的可视化编辑器是无法将体验做到极致的，但是，在特定场景的垂直领域，将变得非常有用了，因为组件具有相似性，封装维度更低，组件配置项更少了。

另外，我需要强调的是，组件编辑器的主要工作是产出展示型的静态组件，即设计稿画出内容。关于交互的实现，可以给这些静态的元素添加逻辑(流程)来实现，这是另外一个话题。