从”快速响应样式调整“的角度思考页面编写

前言

最近正在做一个标准品项目，也即是模板项目，用于后续的快速复制。在页面编写这块，UI层面的需求就是：面对不同客户，需要快速响应页面调整，速度当然是越快越好。

想起之前给客户做定制化服务的时候，UI出一个图，前端配个elementUI，不管三七二十一就直接上手写的开发模式。前期少了点样式结构层面的思考。对于一个标准品来说，始终是不合格的一件事儿，也会欠下太多的技术债。于是，便有了软件设计的学习，以及下文的思考记录。

原先的工作模式：按页面编写

如果从软件设计的角度看上图这个系统，UI是一个模型，它的任务是产出UI图，前端是另一个模型，它的工作是把UI图转换成浏览器可渲染可交互的页面，UI图则是这两个模型之间的交接物（接口)。

以往的解决模式就是，UI画一个图，前端写一个页面，就好像加工厂一样。

优点：

• 前期速度快

  项目本身没有太多复杂的动画效果，直接写是很快的。

可能存在的缺点：

• 多人协同的情况下，不好把控一致的样式/交互

  • 最终效果可能不同。UI图大部分情况下只是一个切面，不同的人可能写出不一样的交互效果。
  • 效果相同，但解决方案可能不同。这个时候，哪种写法更优呢？

• 各页面间存在相似的样式代码

  如果最终效果相同，解决方案也相同，那各页面间其实存在很多的重复代码。

• 覆盖组件库底层样式的情况太多

  这对于渲染效果来说，其实是存在很大提升空间的。

从快速响应用户需求的角度编写页面

前端开发拿到UI图的第一步，不应该是直接写代码。

因为UI设计师接到需求的第一步，也不是直接画图，而是先设计基本色调，定义设计元素等。同样的，前端也应该先去理解UI图，寻找重复出现的图案，提取设计元素。

有了第一步之后，就能利用第三方组件库的样式变量，进行最基础的modifyVars修改。每提取一个样式变量，都可以减少后续的样式编写，也就少了很多重复代码。

如果样式变量不能满足需求，那么就只能覆盖组件库样式了。但也不能在页面样式中去覆盖，因为它还是属于全局的样式，更准确地说，是属于组件的样式。所以，我的做法是单独新建了一个公共文件，把组件样式统一起来，且各组件样式之间相互隔离。

得到优化的点：

• 页面渲染

  • 减少了浏览器的重复渲染
  • 样式文件的体积也缩小了

• 需求开发

  • 把组件层级的样式更改统一到了一个地方
  • 后期的页面编写速度会更快

分离关注点，寻找不变的东西

软件设计很重要的一点就是，分离关注点，我们要去寻找不变的东西，将系统稳定下来。

对于页面来说，我做了如下两步的思考：

样式细分，寻找不变的样式

• 大小，不容易变的

• 色彩，容易变的

  色彩几乎是一定会变的，所以，除了基础色系外，我还把组件色彩提取到了同一个地方，就和仪表盘一样，很容易能修改到每个组件的色彩。

样式封装，寻找不变的样式类名

以做什么去命名样式类名，而不是以怎么做去命名。

其实btn-orange的组件样式命名也没错，但如果需要随时调整主题色，下面这种做法会更好一点。

• btn-orange 橙色按钮，主题色变更—>类名不对—>对应的引用也不对
• btn-sub 辅助色按钮，主题色变更—>类名正确—>对应的引用仍然正确

如果是btn-sub的类名命名，只需要修改类名下的样式即可，完全不需要修改页面引用，也较少了开发工作量。