(总结)我的项目经验一次更换ui组件库才晓得的事: 共21种问题类型
介绍
写这篇文章的起因是作者不久前经验了一次我的项目整体ui组件库的替换, 本认为更换ui组件库只是改改款式并且改几处写法就行了, 但真正经验了才晓得这外面遇到的问题还真是丰富多彩, 全程做下来我一共总结了21种问题类型, 心愿哪一天你也有相似’需要’的时候能够找进去这篇文章看一看。
我经验的场景是公司外部研发了新的组件库, 新组件库大部分的’应用形式’和’设计理念’与旧组件库是统一的, 并且是公司外部的库所以不不便间接截图举例子, 文章里我就用antd来类比展现我遇到的问题, 顺带一提ts真香在更换组件库时立了大功, 很多问题都是开发人员很难间接监测到的只能靠 ts。
一: 属性的变动
属性被删除 (ts可标红)
比方 button组件之前有一个 textType用来设置按钮的定制款式, 然而在新的组件库中被删掉了, 这些旧的非凡款式须要找ui同学确认是否保留。
新增属性
弹出框新增autoFocus属性, 是否默认聚焦第一个可聚焦元素，如果组件库应用新增属性是为了代替某个旧属性的话, 那么替换时就须要找到属性间的对应关系。
属性改名 (ts可标红)
比方弹框的确认按钮, 之前叫onConfirm事件, 当初叫onOk事件。
属性取值范畴扭转 (ts可标红)
旧版组件button的size属性取值范畴是 big mini small , 新版组件库变成了default large, 呈现了三种属性对应两种属性的问题, 这个时候就要找ui同学来决定如何替换了。
二: 返回值的变动
类型变动 (ts可标红)
咱们的 日期组件 的 onchange事件旧版返回的参数是被dayjs解决过的对象, 间接能够针对这个值进行格式化的取值, 然而新版组件返回的是工夫戳, 这种组件替换的时候须要咱们被动为其转换一下格局:
旧版
onChange={(_: string[], date: Dayjs[]) => {
const startTime = date[0];
const endTime = date[1];
// ...
}}新版
onChange={(_: string[], date: number[]) => {
if (date[0] && date[1]) {
const startTime = dayjs(date[0]);
const endTime = dayjs(date[1]);
// ...
}
}}数量变动 (ts可标红)
比方之前返回值是两个, 然而当初合成了一个对象外面的两个key返回给咱们, 这时候要做一下构造再应用。
三: 限度条件的变动 (可能是bug)
InputNumber 数字输入框限度条件变了, 比方设置最小值为 1, 当我输出0的时候输入框会默认把值转为1, 然而新版输入框居然在我输出0的时候没有把值转为1, 这就导致接下来的所有操作都须要对是否为0进行校验。
这类问题才是最"要命的", 会导致原有变量的变动, 并且不实际操作一遍无奈发现问题, 很多组件咱们无奈一一验证, 比方很多组件只在特定的状况下才会呈现在用户的界面上, 这时候咱们很容易漏测一些中央。
四: 显示层级的变动
不光是z-index的问题, 每个组件所处的父级也会导致层级的不同, 比方咱们前置有一个新人引导弹框, 在更换新组建库后这个新人引导弹框 就被遮挡住了,
当新老组件库一起应用的时候, 老组件库的弹出框组件, 与新组件库Tooltip提示框配合应用的时候提示框无奈显示。
这类问题不容易发现, 比方tooltip不显示这个问题, 对于一个不熟悉业务的人来说根本无法发现本来应该有个提示框, 须要开发人员对业务很熟能力发现此类问题。
五: 组件联结应用的bug
咱们有一种输入框组件是能够插入一个 抉择框组件, 然而新版组件外面没有设置为这种插入组件:
旧组件
新组件
这种问题也比拟辣手, 因为它并不会报错, 只是显示不一样, 这就导致只有真切的在页面上看到了这种谬误能力发现。
六: 组件短少
旧版组件库提供了懒加载组件和 谬误提醒组件, 然而新版的组件库没有这两个组件, 这时就须要分割负责的同学了, 看是否能够加上这两个组件, 如果不能加上只能本人亲手开发一个了, 这个问题也挺坑的, 无端减少了不小的工作量。
七: 兜底属性的扭转
旧版组件库的table表格组件会有默认的error谬误图和empty空值图, 然而新版的没有这些图片, 须要咱们手动的去增加。
比方弹出框组件的onOk事件如果不传入的话, 默认点击后是 “敞开弹框”, 然而新版组件外面不传就是没有任何操作成果, 这就须要之前没传onOk事件的弹框每个都加一下。
这类问题也比拟难发现, 因为并不会报错然而到处都有。
八: css属性的错乱 & 款式的差别
元素css属性被扭转
比方table表格组件每个td的差别, 旧版组件外面没有为td设置非凡的属性, 然而新版的表格组件为tb设置了display: flex属性, 这可把一堆款式都搞乱了, 几乎惨不忍睹。
弹框组件的footer没有用div之类的标签包住, 导致被父级的display: flex影响, 比方我独自定义footer为一个按钮的话, 这个按钮会被抻拉。
这类问题不好解决, 因为新的ui库的同学也不违心改这种底层设计,而且新版的ui库曾经有其余团队在应用了, 此时就须要咱们本人写全局的css款式把它顶掉了。
整体款式未解决
新版组件库没有为组件增加box-sizing: border-box;属性, 我以后的我的项目里也没有写*{box-sizing: border-box;}, 就导致很多中央的款式都会有2px左右的偏移, 看起来非常顺当, 这类问题只能加css款式来解决了。
九: style || className 设置有效 (ts可标红)
这个问题也是无意间发现的, 新版的ui库局部组件不承受style参数了, 导致之前很多款式都不失效了, 然而咱们也没法通过css的形式把款式注入进去, 这个挺无解的, 只能找相应的同学扩充一下新版ui组件的接管值范畴。
十: 组件标签嵌套的扭转
比如说弹出框组件, 本来弹出框组件有两层div包裹, 当我想要获取最外层的div时就须要以后元素.parentNode?.parentNode, 然而新版ui组件嵌套关系改了, 并且多嵌套了一层, 导致之前获取最外层元素的办法全副报错。
这里也让咱们意识到, 最好不要写这种获取dom的操作, 标准的模式应该是应用组件提供的办法获取组件的任何元素, 并且设计组件的时候也要把获取元素的办法导出来。
这种问题也不好发现, 只能是真的触发了获取父级的办法, 能力报错进去。
十一: 组件未做国际化
这个问题比拟直观了, 当咱们批改用户的语言时, 组件未依据咱们抉择的语言进行语言的变动, 这种性能发现之后让对应同学加一下就好了。
十二: 独自写的组件
有这样一种非凡情景, 在应用旧组件库的时候, 某个组件的性能不能满足开发的需要, 过后的开发同学本人写了一个与组件库里的组件款式截然不同的组件, 这个组件可能传参的规定是独立的, 无奈与新的组件库无缝替换。
全局替换新组件库后, 实际上上述的组件并没有被替换, 它还是放弃旧版ui的款式, 因为它是独自编写的所以也不会报错, 但就是款式的改版须要咱们独自为其编写一下, 也挺累人的。
这个问题也比拟辣手, 因为切实是好难发现, 发现了批改起来也不是设想中的那样容易, 给我的启发就是当前进行应用组件库提供的组件进行开发, 本人写的组件无奈进行更好的更迭。
十三: 款式变量的扭转
比方旧组件库外面定义红色分为red-01, red-02, red-03几种类型的class名或者css变量, 别离示意深与浅的红色, 我的项目代码中也同样引入了旧组件库提供的这些变量。
新组件库外面也有一套本人的css 或者 scss 变量, 命名与之前的齐全不一样, 这导致比方我之前应用red-01当初要改成color-obvious, 像这种css变量之间的对应关系可能须要写个函数循环比对, 然而不好的是他们的rgba色值很可能齐全不一样, 这就导致齐全无奈一一对应, 头疼不已。
这类问题只能一个一个的和ui比照了, 这里给我的启发就是哪怕一个小小的css变量, 都须要一套残缺的命名标准来设计才行。
十四: 循环进去的未知属性
下面我讲过了, 某些属性的取值范畴可能变动了, 比方button的size属性的取值范畴从 big mini small , 新版组件库变成了default large,这个是眼睛能够看到的, 然而有一种状况就惨了。
这里的举例写法:<button size={btSize}>ok</button>这外面的btSize是一个下层组件传递过去的变量, 这时ts可能会不报错然而它依然会呈现取值谬误的问题。
要为这种状况专门写一下转换属性的办法比方:
let size = 'default';
if(btSize === 'small' ){
size = 'large';
}这里用button举例是因为它比较简单, 理论状况比这个要难解决。
十五: 用法的拆分
比方弹出框组件旧版组件库导出一个Modal, 能够间接<Modal/> 也能够Modal.info()调用弹出框, 新版将它分为 modalFn办法 与 Modal组件。
之前的好多写法都要拆解替换, 每页都要查看不能脱漏。
十六: 旧ui 与新ui一起应用出错
当应用弹框组件与下拉框组件联结应用的时候, 如果点击下拉框组件唤出下拉框, 弹框组件外部产生 ‘滚动’,下拉框组件 的下拉框还是停留在原位。
新旧组件库独特应用是存在危险的, 因为它们有可能基本就无奈相互配合, 而且新组建的同学也不违心修复这种 “问题”。
十七: 组件性能的抽离
比方旧版input输入框组件产生谬误的时候, 咱们会传一个errortip='不能够为空'这类的属性, input就会呈现红色的提示框与下方的提示信息, 然而新版组件库将这个性能齐全放在<FormItem></FormItem>这个标签外面, 也就是说如果咱们想让input框呈现谬误提醒就要, 包一层<Form>再包一层<FormItem> , 但咱们理论有很多中央并不适宜这样做。
这种能力剥离的改版, 个别就是对业务了解的不同导致的, 如果诉求正当的话最好能把这个属性加回来。
十八: 整体类名的变动
css文件中, 这是一个必须解决的问题, 因为咱们会写一些全局的css款式, 比方某个组件内的某个元素必须30px宽, 之类的属性吧, 然而更换组件库后组件的类名齐全变了, 咱们须要改掉这个名字。
js逻辑中, 有可能呈现依据某个类型获取元素的状况, 这种状况最好也全局改一下。
十九: 代码库品质问题 例如ts报错
应用一套代码库的时候, 就好拉他的代码到本地看一看, 比方他是否逻辑谨严, 取值是否做了很多容错, 比方xxx.vvv.bbb还是xxx?.vvv?.bbb, 并且要看他的ts类型是否齐备, 比方写了一些any或是在页面上放了很多/* eslint-disable */ 或者 // @ts-nocheck 那就倡议审慎接入把。
二十: 组件挂载dom不同
这是个挺别致的bug, 配角是旧版弹框组件, 比方在编辑页面弹出是否要来到本页的提醒, 用户页面路由发生变化这个弹框也就主动销毁了, 然而新版弹框组件并不会销毁, 因为它默认是挂载在body身上, 这就导致很多弹框关不掉, 切换了页面这个弹框还是在屏幕上。
这种状况要不就找对应同学修一下, 要不就每个操作都被动加一个销毁以后弹框的操作。
二十一: 人力不足
人力是很要害的问题尤其是 新组件库侧同学的人力, 很多问题被发现但又无奈2日内解决, 这种状况很容易造成 “开发工夫拉锯战”, 所以倡议相似我的项目须要在新的ui库有专门的开发同学专项反对的状况下进行替换, 咱们与其配合实现这个艰巨的工作。
end
这次就是这样, 心愿与你一起提高。
发表回复