设计前端库的一点思考

103 阅读3分钟

笔者其实并没有设计过大型的前端库,只在项目中做过很多组件/逻辑的封装逻辑.对于如何设计前端库这个点谈起来多少有点忐忑,不过在之前阅读很多库的源码基础上,也会吸取一些比较不错的想法.在项目的代码中也用过很多前端库,相信大家在使用很多库的时候,会有很好用和好难用的想法. 本文主要梳理一个'好'用的前端库设计的一些思考,欢迎一起讨论.

约束能力

一个好的设计库可以'教育'开发者.这里说的应该是通过一些约束手段,能让大家形成一种默认的最佳实践.比如:

  • redux的单向数据流.在修改全局store的使用,需要触发action去修改store的数据,数据的更改会通过发布订阅的方式更新页面
  • ESLint 通过ESlint可以限制一些容易出错代码的写法
  • ProComponentsProTable组件就对代码中普遍的loading行为进行了封装.

在考虑约束能力这个问题上,想到在进行项目技术架构的设计的时候,在最底层通常是最通用的能力,在逐层向上的过程中功能更加具体.这个时候在层级之前加入更多约束能力的思考,就能更加整体项目的稳定.

功能隔离(分层)

分层是一个老生常谈的问题,分层的目的就是为了解耦增加后续的可扩展,也一定程度上提高代码的可维护性.在功能分成设计上有一些比较好的例子:

  • React React在功能实现上会拆分多个模块.有负责创建节点结构的包、负责计算渲染任务的包、负责调度任务的包.
  • 插件化设计 插件化的设计思考就能将分支逻辑和主干逻辑隔离,减少耦合度

有限度的封装

在进行库的设计的时候,要明确当前的库的功能,在这个功能基础上有做限度的封装.当封装功能过多的时候,就容易在易用性和功能设计上存在考虑不到的情况,在内部进行功能迭代的时候也会越来越复杂.

性能/使用上的思考

需要考虑整个库对使用者的影响.

  • 在性能上,是否会有渲染性能问题\包体积问题\一些通用优化策略的使用
  • 在使用上,是否对其类似的同类产品(迁移切换成本)\对代码入侵程度(接入成本)

外部接口设计

对外的属性和配置是用户使用库的主要方式,还有一些其他的方式可以为库增加更多灵活性的功能. 比如:

  • 通过ref将内部实例的相关属性暴露出去,作为获取内部状态的一个后门,可以实现更加灵活的功能
  • 内部关键逻辑订阅能力 比如webpack就结合Tapable实现了在编译过程中关键事件的订阅
  • 生命周期能力 在基于特定业务场景的封装时,可以结合特定的场景实现生命周期能力的设计,这样使用者就能在特定的阶段实现特定的业务逻辑.