• 设计公共组件需要注意什么


    本文源于我们近期 抽取以及维护 ListFrame[参考中有介绍] 公共组件 的思考 。
    抽取一个公共组件,至少应当仔细考虑一下4点:

    1、公共组件不应该集成定制性强的功能,可以集成通用或较固定的功能,但应默认关闭那些不常用的功能

    只有极少数列表用到的功能就不要封装了,封装他们 增加了公共组件的代码量,但又没有很高的利用率。

    几乎所有的列表都可以用到,但不同种类的列表 表现不一样(如内容类别搜索,文章类型的类别,游戏类型的类别 完全不同),就是定制性很强的功能了。
    定制性很强的功能封装起来需要包含各种情况,逻辑较复杂,另外也使列表的逻辑分散,不利于维护。试想一下,下次再扩展一个类型,岂不是还要修改这个ListFrame !
    (公共组件不能保持稳定的,就是失败的)

    这有点小儿科了吧!
    实际上识别出哪些功能是通用的(应该封装的),哪些是常用的(应该默认开启的),不能光靠拍脑袋,使用公共组件的过程,不断修正总结 很重要。
    维护公共组件,你一定要有一颗开放的心态。组件好不好,由使用的情况说了算,敢于承认失败,才能不断改进。

    2、参数的配置要简单且灵活

    如果你想让你的组件功能强大,通过配置就能快速扩展,那么一定要避免将配置设计的过于复杂。
    配置复杂,无异于将写源码的工作量 转移到了写配置上,没有任何好处,反而让代码更难理解(额外的要先理解你的公共组件)。

    将配置设计的简单关键就是:用好默认值和类型重载

    构建列表框架,你必须要考虑分页:
    有些列表(如展示全部内容的列表)是没有分页
    分页有pageNo和pageSize属性,且初始值是可以设定的,ajax请求时携带的参数名最好也是可以配置的
    于是可能你的组件应该这样使用:

      <list-frame :showPager="{
    show:true, pageNo:{ name:'pageNo', initial:1 }, pageSize:{ name:'pageSize', initial:10 }}"
    ></list-frame>

    后台在设计接口时,通常参数名就是 pageNo 和 pageSize;前端使用场景中基本上初始的pageNo是1,pageSize为10。采用默认值,所有的配置都可以省略:

    <list-frame :showPager="{show:true}"></list-frame>
    <!-- 没有传入的字段,就使用默认值,而非空(做好空值适配很重要) -->

    为了更简单,再加上类型重载。完整设计代码如下:

    class PagerConfig{
        show?:boolean,
        pageNo?:{
            name?:string,
            initial?:string
        }
        pageSize?:{
            name?:string,
            initial?:string
        }
    }
    
    // 类型重载
        showPager:Boolean | PagerConfig
    
    // 默认值的定义与使用:
    const defaultPager = {
      show: true,
      pageNo: {
        name: 'pageNo',
        initial: 1
      },
      pageSize: {
        name: 'pageSize',
        initial: 10
      }
    };
    
    this.pagerConfig = Object.assign(
      {},
      defaultPager,
      typeof this.showPager === 'boolean' ? { show: this.showPager } : this.showPager
    );
    // this.pagerConfig 就是最终的配置了!

    那么使用时,就可以这样写了

    <list-frame :showPager="true"></list-frame>
    或:
    <list-frame show-pager ></list-frame>

    现在可以看到,一切变的非常简单,同时又保持了足够的灵活性!(灵活性是指,任然可以灵活的配置参数名称 和 初始值)

    3、相关的配置要集中

     将相关的配置集中在一起,更利于用户使用,可读性更强。

    ListFrame 封装了 批量删除 和 批量上下架 的功能。为什么要将这两个功能封装呢?因为:
    1、有很多业务无关逻辑值得我们去封装,如disable校验,删除和下架时要弹出输入框,要求用户输入删除原因或下架原因;
    2、通用性很强,几乎所有的列表都有删除功能,所有已发布列表都有上下架功能;
    3、不同列表除了对应的上下架接口,删除接口不同外,好像没有什么其他不同的。

    看看下方代码:

        <!-- 集中配置前: -->
        <list-frame
          :getPageFn="getPage"
          :itemsDelAble="true"
          :delFn="delFn"
          :shelfOperateAble="true"
          :offshelfFn="offshelfFn"
          :onshelfFn="onshelfFn"
        ></list-frame>

    如果开启批量删除 除了设置 itemsDelAble 为 true,还要提供 delFn 删除方法;
    如果开启批量上下架 除了设置 shelfOperateAble 为 true ,还需要提供 offshelfFn 和 onshelfFn 两个方法。

    既然提开启功能和供方法必须同时存在,为什么不把他们绑定在一起呢?我们将 itemsDelAble 和 shelfOperateAble 有bool类型变成了 object 类型,于是很容易实现了集中配置的目标。

    对比一下将配置集中前后的代码,是否后者更容易理解,更方便使用了呢?

        <!-- 集中配置后: -->
        <list-frame
          :getPageFn="getPage"
          :itemsDelAble="{delFn}"
          :shelfOperateAble="{offshelfFn,onshelfFn}"
        ></list-frame>

    4、避免出现职能交叉的配置

    我发现,这一点错误,即便是大型UI框架也会犯。我现在开发的项目所采用的UI框架,关于Button就存在这个问题。下面就用个api截图来说明:(就不发 链接,也不指明是哪个框架了)

    按钮的 type 大部分值都是表示主题颜色的,如default,primary,info等,但 text(文本按钮) 和 dashed(虚线框按钮)除外,我觉得这两个应该是属于shape(形状)的值。
    这样的 type 和 shape 职能交叉了。现在要实现一个文本按钮,有不同颜色 —— 竟然做不到了!

    我们在开发 ListFrame 也存在这样的错误,后面使用时发现后才改正的,这里就不说了,因为上面举的例子已经能很好的说明这个注意点了。
    总之设置配置项时,保持高内聚,低耦合的原则是不变的!

  • 相关阅读:
    bzoj 1004 burnside 引理+DP
    bzoj 3453 数论
    HDU 2899 三分
    HDU 2199 二分
    bzoj 3450 DP
    bzoj 1197 DP
    bzoj 2121 DP
    bzoj 2258 splay
    bzoj 1296 DP
    Memcached的限制和使用建议
  • 原文地址:https://www.cnblogs.com/zhwc-5w4/p/13329818.html
Copyright © 2020-2023  润新知