（总结）项目改ui组件库后才知道的事：共21类问题介绍写这篇文章的原因笔者前不久经历了项目整体ui组件库的更换。原以为更换ui组件库只是换个样式，改几个写法而已，但真正体验过后才发现，这里遇到的问题真是丰富多彩。整个过程做下来，我一共总结了21种题型。希望有一天，当你有类似的“需求”时，你会发现这篇文章并看一看。我经历的场景是，公司开发了一个新的组件库，新组件库的大部分'用法'和'设计理念'与旧组件库是一致的，是公司内部库，所以不方便直接以截图为例，文中我用antd来类比展示我遇到的问题。顺便说一句，ts振祥在替换组件库方面立下了汗马功劳。很多问题开发者很难直接监控，只能依赖ts。一：Attribute变化属性被删除（ts可以用红色标注）比如按钮组件之前有一个textType用来设置按钮的自定义样式，但是在新的组件库中被删除了。这些老的特殊样式需要找ui同学确认是否保留。新属性弹出框增加autoFocus属性，默认是否聚焦在第一个可聚焦元素上。如果组件库使用新属性替换旧属性，则替换时需要找到属性之间的对应关系。属性重命名（ts可以用红色标注）比如弹框的确认按钮，之前叫onConfirm事件，现在叫onOk事件。属性取值范围变化（ts可以用红色标出）旧版组件按钮size属性取值范围bigminismall，新版组件库变成了defaultlarge。存在三个属性对应两个属性的问题。找ui同学决定怎么替换。二：返回值的变化类型变化（ts可以用红色标注）我们date组件的onchange事件老版本返回的参数是dayjs处理过的对象，可以直接格式化为这个值，但是新的组件的版本返回是一个时间戳。当这种组件被替换时，我们需要主动转换格式：旧版本onChange={(_:string[],date:Dayjs[])=>{conststartTime=date[0];const结束时间=日期[1];//...}}新版本onChange={(_:string[],date:number[])=>{if(date[0]&&date[1]){conststartTime=dayjs(date[0]);constendTime=dayjs(date[1]);//...}}}数量变化（ts可以用红色标注）比如之前返回值是两个，现在二合一对象合成了一个key返回给我们。这时候我们需要先做一个结构体再使用。三：限制条件的变化（可能是bug）InputNumber数字输入框限制条件发生了变化，比如设置最小值为1，当我输入0时，输入框会默认将值改为1，但是新版本输入框的of实际上是在我输入0的时候，值并没有转换为1，这就导致在后面的所有操作中都需要检查是否为0。这种问题是最“致命”的，会导致原来的变量发生变化，不实际操作是发现不了问题的。我们无法一一验证许多组件。例如，很多组件只有在特定情况下才会出现在用户面前。在界面上，这时候我们很容易漏掉一些地方。四：显示层级的变化不仅仅是z-index的问题，各个组件的父层级也会导致层级不一样。框被遮挡，当新旧元件库一起使用时，旧元件库的弹出框元件和新元件库的Tooltip提示框无法显示。这种问题不容易发现。例如，工具提示不显示此问题。对于一个不熟悉业务的人来说，是不可能发现应该有提示框的。需要开发人员熟悉业务才能发现此类问题。五：联合使用组件的bug我们有一个输入框组件，可以插入一个选择框组件，但是新版本的组件没有设置插入这种组件：老组件和新组件这个问题也是比较难，因为不会报错，只是显示不一样，导致在页面真正看到这个错误才发现。六：组件缺失老版本的组件库提供了懒加载组件和错误提示组件，但是新版本的组件库没有这两个组件，这时候需要联系负责的同学看看能不能添加这两个组件，如果不加，只能自己开发一个，而且这个问题比较棘手，无缘无故增加了工作量。七：bottom-up属性的变化老版本组件库的table组件会有默认的错误图片和空值图片，而新版本没有这些图片，需要我们手动添加。比如弹出框组件的onOk事件如果没有传入，默认的点击会是“关闭弹出框”，但是如果在新版本的组件中没有传入，就会有没有运行效果。这就要求每个之前没有传过onOk事件的弹出框都被触发一次。这种问题也比较难找，因为不报错却无处不在。八：css属性混淆&样式差异元素css属性改变比如table表格组件的各个td的区别，老版本的组件没有为td设置特殊属性，但是新版的table组件设置了tb的display:flex属性，这搞乱了一堆样式，太可怕了。弹出组件的footer没有用div等标签包裹，导致受父级display:flex的影响。比如我把footer单独定义成一个按钮，这个按钮就会被拉伸。这种问题不好解决，因为新的ui库的同学不愿意改动底层设计，而且新版的ui库已经被其他团队使用了。这时候我们就需要写全局的css样式来topitLost。整体样式未处理新版组件库未添加box-sizing:border-box；属性给组件，而我现在的项目中没有写*{box-sizing:border-box;}，这样会导致很多地方的样式都有2px的左右偏移看起来很别扭，而且这种问题只能通过添加css样式来解决。九：风格的设置||classNameisinvalid(tscanbemarkedinred)这个问题也是无意中发现的。新版ui库的部分组件不接受style参数，导致之前的很多样式失效，但是我们不能通过CSS的方式向里面注入样式，这个就比较无解了，只能找对应的了同学们扩大了新版ui组件的取值范围。十：组件标签嵌套变化比如弹出框组件，原来弹出框组件有两层div包裹，当我要获取最外层的div时，需要当前元素.parentNode？.parentNode，但是新版的ui组件nested改变了嵌套关系，多了一层嵌套，导致之前获取最外层元素的方法都报错。这也让我们意识到，获取dom这种操作最好不要写。标准模式应该是使用组件提供的方法来获取组件的任意元素，并且在设计组件时，获取元素的方法也应该导出。这种问题不容易发现，只有真正触发了获取parent的方法才会报错。十一：组件没有国际化这个问题比较直观。当我们修改用户的语言时，组件不会根据我们选择的语言改变语言。发现这个功能后，让相应的同学加上去。十二：单独编写的组件有一种特殊情况，在使用旧的组件库时，某个组件的功能不能满足开发需要。组件，这个组件可能传参的规则是独立的，不能无缝替换成新的组件库。全局替换新组件库后，上述组件实际上并没有被替换，依然保持老版本ui的风格。因为是单独写的，所以不会报错，但是样式的修改需要我们单独写。也挺累的。这个问题也很难，因为真的很难找，也没有想象中那么容易修改。对我的启发是，以后的开发都是使用组件库提供的组件，自己写的组件再好不过了。改变。十三：样式变量的变化例如在旧的组件库中，red被定义为red-01、red-02、red-03类型的类名或css变量，分别代表深红色和浅红色，同样是true在项目代码中引入了旧组件库提供的这些变量。新的组件库也有自己的一套css或者scss变量，而且命名和之前完全不一样，导致比如我之前用的是red-01，现在要改成color-明显的。这样的css变量之间的对应关系可能需要写一个函数进行循环比较，但是不好的是它们的rgba颜色值可能完全不同，导致完全不能一一对应，这是一个令人头疼的问题。这种问题只能和UI一一对比。这里对我的启发是，即使是一个很小的css变量，也需要一套完整的命名规范来设计。十四：Unknownattributesfromtheloop上面我说了一些属性的取值范围可能发生了变化，比如按钮的size属性的取值范围从bigminismall变了，新版本的组件库已更改为默认大。这是肉眼能看出来的，但有一种情况，惨不忍睹。下面举例写法：
