谈谈前端工程中的复用和通用化(二)

上一篇说到
“我们项目组,现在有多个项目和工程,这些项目和工程有很多代码功能是相似又不完全相同,相似的代码多次开发,对开发效率是一中浪费。所有用了以下的结局方案,来提高几个业务线的代码“复用”性。”
在复用的过程中,有几个重要的角色,这篇就说下其中一个角色-“组件”


这篇文章大概说下在通用性这块,组件是如何设计和划分。

我们组用的是内部mvvc框架,但是用法和思想和外界的vue等也很相似,工程开发中的思想是通用的。

组件主要分两种:

  1. 跟业务无关的通用组件:例如input/buttton/list等等
  2. 强相关的业务组件:例如标签组件/过滤器组件

1.通用组件:

1
2
可配置性,是组件比不可少的重要功能。那分析一道:一个完整的组
件应该如何组成?大概下面四点。

  • 配置机制: 组件在被其他组件或者模块使用的时候固定的使用参数配置(和vue/react相似,也就是通过组件属性配置) 另一类是当组件被接入到业务线后就固定的业务统一配置信息,不同的业务线有不同的配置,通过读取业务线全局配置来做。
  • 组件逻辑:组件的核心功能实现,主要维护组件抽象出来的数据模型,为组件结构或者使用者提供属性访问、接口调用、事件回调等
  • 组件结构:组件的结构,其实就是模版,模版中使用组件逻辑层暴漏出的数据/事件/接口等来完成信息发布和展示。在数据驱动的开发思想想,不应该在模版中做太多的操作,较复杂的逻辑要放到组件逻辑层来处理,通过数据驱动模版变化。
  • 组件样式:样式可以抽象出两种:1.每个业务线自己独特的皮肤样式(字号,颜色,背景等)2.业务线一般不会配置的样式,如组件的展现形式,形状等;
    第1种样式如何配置?,可以通过皮肤的形式来配置,字号,颜色这种属性不在css里写死,而是通过calss在dom属性上,例如 14px,#333 的字体对应的 class是 fs2cl3; 每个业务线中有一套自己的皮肤文件:

    1
    2
    3
    A业务线中: .s2cl3 { font-size: 14px; color:#333}
    B业务线中: .s2cl3 { font-size: 12px; color:#666}
    在组件中凡是涉及到可配置的样式,不会在自身的样式文件中来写,都通过class来控制,每个业务线有自己的一份class皮肤,就能做到样式可配置

    这里组件结构和组件样式可以根据不同的平台自己定制,然后将逻辑、结构、样式组装成一个完整的UI组件给到上层业务使用,如果业务有需要深度定制的情况下可以重写结构、样式,通用业务逻辑实现部分可重用


组件逻辑部分,其实是复用性最高的,web端组件,wap端组件,大的差别还是在样式和结构上。所以一个组件的抽象可以如下图:
此处输入图片的描述

1
同一套逻辑,可以对应不同的结构和样式文件,复用逻辑部分,重写结构就能完成wap/web两个展现形式的组件


同样:业务线想重度定制组件,可以继承组件逻辑,重写逻辑中的同名方法,并且可以重写组件的结构部分。


2.强相关的业务组件:

  • 业务组件一般会组合数据层(cache)形成一个更大粒度的复用单元,而通用组件一般不建议直接组合数据层强绑定特定数据源.

  • 业务组件,一般提供给特定的业务模块使用,组件内部可能耦合一部分数据相关的逻辑,夸场景复用的情况较少(不过复用,重写,和配置是和通用组件相同的,只是使用场景有些变化)。

如下图:
此处输入图片的描述

编写一个组件的总结:

  • 一个组件编写时,要主要配置性,和暴漏接口/事件的合理,个人认为一个编写通用组件是,不要考虑它的使用场景,一个组件长什么样子,取决于实例这个组件时传的参数和配置,组件可以看作一个函数,你给特定的参数,它就返回特定的姿态。
  • 组件内部的数据,应该是保持自我封闭,自我操作。和外部通信和交互,通过事件维护,做到组件内部是一个干净的环境,不关系外界,适当的时候只需要抛出(emit)出对应的事件和数据就行了。

作者 [@sha Qihe]

2017 年 6月 20日