Skip to content
On this page

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

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

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

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

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

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

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

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

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