框架要考虑的问题:
- 我们的框架应该给用户提供哪些构建产物?产物的模块格式如何?
- 当用户没有以预期的方式使用框架时,是否应该打印合适的警告信息从而提供更好的开发体验,让用户快速定位问题?
- 开发版本的构建和生产版本的构建有何区别?
- 热更新需要框架层面的支持,我们是否也应该考虑?
- 当你的框架提供了多个功能,而用户只需要其中几个功能时,用户能否选择关闭其他功能从而减少最终资源的打包体积?
提升用户的开发体验
衡量一个框架是否足够优秀的指标之一就是看它的开发体验如何。
在框架设计和开发过程中,提供友好的警告信息至关重要。
控制框架代码的体积
框架的大小也是衡量框架的标准之一。
在开发环境中为用户提供友好的警告信息的同时,不会增加生产环境代码的体积。
框架要做到良好的 Tree-Shaking
简单地说,Tree-Shaking指的就是消除那些永远不会被执行的代码,也就是排除 dead code ,现在无论是 rollup.js 还是 webpack,都支持 Tree-Shaking。
想要实现 Tree-Shaking,必须满足一个条件,即模块必须是 ESM(ES Moudle),因为 Tree-Shaking 依赖 ESM 的静态结构。
Tree-Shaking第二个关键点——副作用。如果一个函数调用会产生副作用,那么就不能将其移除。什么是副作用?简单地说,副作用就是,当调用函数的时候会对外部产生影响,例如修改了全局变量。可以用 /#PURE/ 注释。
框架应该输出怎样的构建产物
iife、esm、生产包、测试包、cjs等。。
特性开关
在设计框架时,框架会给用户提供诸多特性(或功能),例如我们提供A、B、C三个特性给用户,同时还提供了a、b、c三个对应的特性开关,用户可以通过设置a、b、c为true或false来代表开启或关闭对应的特性,这将会带来很多益处。
- 对于用户关闭的特性,我们可以利用Tree-Shaking机制让其不包含在最终的资源中。
- 该机制为框架设计带来了灵活性,可以通过特性开关任意为框架添加新的特性,而不用担心资源体积变大。同时,当框架升级时,我们也可以通过特性开关来支持遗留 API,这样新用户可以选择不使用遗留API,从而使最终打包的资源体积最小化。
可以用 rollup.js 的预定义常量插件或者 webpack.DefinePlugin 插件来实现。
错误处理
错误处理时框架开发过程中非常重要的环节。框架错误处理机制的好坏直接决定了用户应用程序的健壮性,还决定了用户开发时处理错误的心智负担。
良好的TypeScript类型支持
使用TS的好处有很多,如代码即文档、编辑器自动提示、一定程度上能够避免低级bug、代码的可维护性更强等。因此对TS类型的支持是否完善也成为一个框架的重要指标。