关于组件提示信息打印

[yinhw0210]

写在前面

在前端项目中，由于js本身是一个弱类型语言，虽然有了ts的加持（个人认为ts并不能把js提升到强类型语言），但是由于浏览器环境的复杂性、网络问题、亦或者是开发者对组件库的不熟悉等，都会影响组件库的使用体验。所以错误及警告信息的抛出显得极其重要。举个栗子，联合组件的嵌套使用、组件入参多类型判断、非法入参、组件迭代弃用api提示等你不可能全部都在代码层面做出判断，所以都需要给出合理的提示信息。方便开发者快速定位并处理问题，提高开发体验。

方法抛出

log 对象 of 类

处理函数

warning：输出警告信息，给出警告提示。
warningOnce：对于一些嵌套循环组件的异常判断，只给与一次警告提示。
error：输出错误信息，给出错误提示。
errorOnce：对于一些嵌套循环组件的异常判断，只给与一次错误提示。
info：输出基础信息。

函数入参

componentsName：组件名称。
message：提示信息。

输出示例

FightingDesign Slider Warn: max should be greater than min

环境区分

对于生产环境是否需要错误打印可以抛出一个全局配置，供用户选择。

写在最后

组件库基于MIT开源，面向All Developer ，所以建议使用英文提示。
如有不足或错误，欢迎补充及纠错。

[Tyh2001]

确实，目前有些组件的必要配置项决定了这个组件的展示方式，如果传入了非法的参数，虽然有props 校验，但这仅仅会给予警告日志，并不能根本的做出更好的 props 校验和修正。未来其实捕获到这个错误信息，用来修正 props，以免参数不是和法值导致组件崩溃或不能正确的工作。

[yinhw0210]

对 我在想的时候也是感觉这个和异常捕获有点冲突，但是如果把他当成一个工具函数的话就不冲突了，重要代码的异常捕获还是用new Error()去实现就行了。

[Tyh2001]

但是还有一些需要权衡的是：用户在使用中，会不会因为经常遇到这种 props 的报错日志，大多数的时候都是去解决了组件的问题，而不是用更多的精力去用在业务层面而会感到厌烦？毕竟组件库是用来提高开发效率的，而不是阻碍开发效率的。

或许我考虑多了？也许用户可以根据文档配置好合法的参数

你怎么看？

[yinhw0210]

提示的作用场景有限，什么时候需要打印错误日志取决于开发者的经验，像是ts能给出的类型提示你没有必要去捕获并抛出来，完全取决于开发者对于自己组件的编写理解，理想状态下复杂的组件可能最多用到一两个提示，简单的组件都没有必要，这就是一个组件库的工具函数，你可以不用，但是不能没有。上面那个silder组件的输出示例算是一个很好的例子。

[Tyh2001]

需要做 tree-shaking 吗？