Skip to content

Latest commit

 

History

History
147 lines (116 loc) · 4.37 KB

【第16期】《Vue组件库建设实践》笔记.md

File metadata and controls

147 lines (116 loc) · 4.37 KB
Raw

分享地址：https://m.qlchat.com/topic/details?topicId=2000001564254694&auditStatus=A

分享人

林溪

饿了么前端架构师

内容

组件和抽象

组件是一种编程抽象，目的是复用。有通用性组件库和业务型组件库。

抽象：什么时候应该抽象成组件？有如下原则（可借鉴但不必完全遵守，视具体业务而定）：

  • DRY原则：Don't repeat yourself——《程序员修炼之道-从小工到专家》 比较极客的一种方式，重复工作工具化

  • 三次原则：rule of three——《重构-改善已有代码的设计》 重复了三次后，才去抽象。因为抽象成本很高，如果一定的重复次数，可以让你更好发现其中的复用规律，更好去抽象。因此也需要平衡抽象和成本之间的关系。

组件设计

  • 高内聚，低耦合 《敏捷软件开发——原则、模式与实践》
    • 内聚型：粒度
    • 耦合性：稳定

至于如何做组件设计和拆分，实际做法可以先做起来，实际情况中再去迭代修改，最终达到我们想要的效果。

  • 粒度

    • CRP——共同复用原则 The Common Reuse Principle 一个组件尽可能只去做一件事

    • CCP——公用封闭原则 The Common Closure Principle 一个组件不应该包含多个引起变化的原因

=> 那么一个组件应不应该引用另一个组件？

理论上是最好不要，依赖的弊端：耦合（高维护成本、不稳定性） => 代码的可维护性大于复用性

但是实际业务中不可能不引用，那如何做到引用的情况下，且保持一定的稳定性呢？

  • 稳定

    • SAP——稳定抽象原则 The Stable-Abstractions Principle 一个稳定的组件应该是抽象的。

    => 父子组件如何依赖？

    • IoC好莱坞原则

    hollywood Principle

    Don't call us, we'll call you.

    子组件的初始化和调用由父组件容器负责。

    • CoC约定大于配置原则

    Convention over Configuration

  • 设计禁区

    • 越界操作
    • 副作用
    • 侵入性
    • 环形依赖
    • 属性繁多（是否一个组件承担功能太多，可否拆分）

组件库设计

  • 设计规范先行 设计规范先行以保持组件库表现的一致性。

    • 统一视觉样式
      • 色彩
      • 布局
      • 字体
      • 图标
    • 统一交互动效
      • 时长、缓动
      • 移动路径
      • 形变、编排

  • 样式分离 需求：主题定制、样式差异化

    • 多种主题
    • 主题定制工具
    • 交互动画扩展

  • 辅助平台/工具

    • 文档
    • 脚手架
    • 示例
    • 迭代

组件库工程化最佳实践

组件管理方案

需求：多组件、多人参与、社区参与、私密性

  • lerna：多包管理工具，https://lernajs.io/，优点：一键安装依赖、自动更新依赖、独立版本管理、非npm包
  • 国际化：i18n
    • 制作语言文件
    • 替换文字
    • 运行时转换
  • 测试方案
    • Karma -> 驱动
    • Mocha -> 测试框架
    • Chai -> 断言库
    • Sinon -> Mock
    • Istanbul -> 覆盖率
    • Jest -> 一站式的测试方案
  • 主题方案
    • 实现：提取全局变量，合理继承、衍生
    • 自定义主题：修改主题样式、覆盖主题样式、组件显示传值，内置样式处理
  • 组件库构建方案
    • webpack：动态生成入口文件 → 版本号复制 → Lint →
      • 构建UMD模块规范输出（浏览器/Node通用）
      • 构建commonJS2模块规范输出（Node）
      • 对每个组件，构建commonJS模块规范输出（Node）
      • 组件之外的公共代码构建（Node）
      • 构建语言文件，UMD模块规范输出
      • 构建主题样式
    • ES模块规范输出：Tree-shaking，只想用其中的一个组件，不想全部引入组件库。
    • GitHub集成：Travis-CI，travis-ci.org开通服务、coveralls.io开通服务、配置.travis.yml
      • 提交代码
      • Travis CI运行
      • 设置环境变量
      • 启动测试
      • 组件库构建、组件提交master、主题提交分支
      • 文档网站构建提交gh-pages
      • 提交覆盖率
      • 成功
    • 文档方案
    • 翻译方案

总结与展望

  • 组件库还是要有的
  • 合理的设计
  • 周围生态很重要
  • 造好轮子是一个脏活累活

分享几个案例：

（本篇完）