前端搞设计规范(夭折记)

556 阅读2分钟

1,现状

  1. antd不满足视觉需求
  2. 视觉定制化严重
  3. 风格不能统一
  4. 细节多,视觉自己也没做到统一

2,想解决方案

自己去搞一套符合视觉的组件,苦逼的要命,但活人不能让尿憋死啊
于是乎开始找轮子,功夫不负有心人,果然找到两个轮子

轮子1: Fusion Design

Fusion简单来说可以总结为以下几点:

  1. 设计在平台上,规范设计规范
  2. 视觉规范输出为sass、less样式变量
  3. 前端使用Fusion组件,编译的时候引用了样式变量,风格随之改变

缺陷 :必须使用Fusion组件,自己写的组件必须手动接入样式变量,否则没卵用

轮子2: imgcook

imgcook简单来说,就是识别设计稿,转换成代码:

  1. 通过imgcook约束sketch设计规范
  2. 通过sketch插件输出源码
  3. 在imgcook转成代码

缺陷 :输出代码命名可读性差,维护成本高

来一套组合拳

虽然上面两个轮子都有缺陷,但想来想去,可以博采众长,将需要的能力组合起来


流程如上图:

  1. Fusion配置视觉主题,输出主题样式变量
  2. imgcook快速输出组件代码,前端修改组件代码,引入Fusion变量

总结: 貌似可行哈,如果这样的话,能够比较快的整理好一套符合设计规范的组件库

3, 夭折

有了想法,优先探索是否可行,且要看是否真正的解决问题,经过讨论,得出以下结论:

  1. 按经验与其搞主题重构,还不如直接重构,因为一旦涉及整体换肤,往往不只是样式上的调整,而是业务上的调整,所以只针对换肤需求,投入产出比严重不匹配
  2. 业务节奏快,没有可沉淀的样式关键点积累,当前快速变化的业务,不适合做这种稳定后的操作

总结:

  1. 当前的业务形态不太符合做这样的工作
  2. 虽然想法夭折了,但这个想法确实有一定的生存空间,在某些稳定的业务形态下说不定会大放异彩,所以特地写篇文章,记录以下。