领导问我，会给这次经历打几分，我说 80。
导师和组长每隔一个月，就会问我，项目进度怎么样，有没有进步，我都不自觉跟他们说些掏心窝子的话。
六个月其实很累，身体明显感觉到了，但我却乐此不疲。我很喜欢我所在的团队，喜欢这的学术研发氛围，喜欢同事牛逼的技术，总想着有一天，期望成为新哥，凯哥，mzj 那样厉害的人物
1.table-item 不显示（没给 table 高度导致）
描述：数据是这样的[{},{}] 对象数组形式，能获取到数据，能成功给 gridOptions 赋值，但就是显示不出
修复思路：
- 有自定义组件
SfTableOptions 和 useTableOptions hook 辅助编码，最开始选第一个，打印 gridOptions 发现是 undefined，然后用第二钟方法。
- 后面觉得数据从获取到赋值这一整个过程都没问题，打印的结果都理想，就猜测是内容高度不够问题。
其实像这种功能正常，数据流也很合理的错误，我犯过好几个，都在想是不是所用的 hook 或方法返回不对，往往遗忘了渲染的条件
2.组件复用过程
描述：认证算法和加密算法非无选项都用到了密码和确认密码小组件，属于高频使用了，在没复用之前，遇到的 BUG 有
- 因为在同一个 form 表单，ref 值相同，这导致在做 radio-switch 表单检验的时候，校验规则不知现在监听的是那个 item 项，导致相同也会报错
解决方案：抽离公共代码，复用成组件，想法是：把 ref 和对应的 disabled 条件传入，在组件中利用组件的 setData 和 getSubmitData 方法拿到传入和传出的数据，在通过 watch 监听那两个 input 的值，进行 ref.value.validate()的标红告警清除
1
2
3
4
5
6
7
8
9
| <snmp-password
ref="X1"
:disabled="" />
watch(() => [A, B], v =>{
ARef.value?.validate();
BRef.value?.validate();
});
|
解决，但来了个需求，认证算法共用一个数据源，就是一个改，切换另一个 radio 也跟着改，用现在的组件实现比较复杂，因为得传入三个 ref 值，得对三个 radio 项进行判断，看是哪个传入，在渲染的时候对页面视图同步不方便，提交也多种分情况。
于是，进一步优化：认证算法共用一个数据源，利用 v-model 传入数据对象进去，子组件在渲染，这样就省去了提交的判断。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
|
const A = ref({
password: '',
confirmPassword: ''
});
const props = defineProps<{
disabled: boolean;
value: {
password: string;
confirmPassword: string;
};
}>();
const emit = defineEmits(['input']);
const formData = computed({
get() {
return props.value || {
password: '',
confirmPassword: ''
};
},
set(v) {
emit('input', v);
}
});
|
完美解决！
3.if else 条件判断性能优化
有这么一个场景：foreach 遍历原始表格数组，对要编辑的表格行进行 key 排查，改行不能先找到改行数据，修改时再看有无重名地址，最后提交，下面是待优化的，用了很多 if-else 条件判断
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| newGridData.forEach((value, index) => {
const trapArray = newGridData.map(item => item.trapAddr);
let same = trapArray.find(value => value == data.trapAddr);
if (value.trapAddr === id) {
if (data.trapAddr === id){
newGridData[index] = data;
isSend = true;
} else if (same === undefined) {
newGridData[index] = data;
isSend = true;
} else {
fail();
}
}
|
优化后，先对不满足的条件判断，接着退出，最后剩下的就是满足的，
1
2
3
4
5
6
7
8
9
| if (value.trapAddr !== id) {
return
}
if (data.trapAddr !== id && typeof same !== 'undefined') {
fail(tr('snmpOptMgt.edit'))
return
}
newGridData[index] = data
isSend = true
|
4.查找元素优化
注释的写法太小白了，我要找的就是所选数组下标，为此专门写了个所有 key 的数组，在通过传入的 key 在这数组查找，在比对，饶了一大远路，忘记了 findIndex 方法，这波是忘记专门的 API，拿到需求直接上手开造造成的逻辑缺陷。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
|
const rowIndex = newGridData.findIndex((item) => item.trapAddr === id)
const sameIndex = newGridData.findIndex(
(item) => item.trapAddr === data.trapAddr
)
if (sameIndex !== -1) {
fail(tr('snmpOptMgt.edit'))
return
}
newGridData[rowIndex] = data
isSend = true
|
5.radio 选择优化
有这么个条情况，两个 radio 的 item 项，有个 change 事件，只在由启用变为禁用的时候，才会触发确认弹框。
于是我我把那两种情况写了个遍，由启用变为禁用，或者初始值为禁用，更改后（还写了变量判定）提交值变为禁用，才触发，很不错啊，思路很清晰。但这条件一判定下来，就又臭又长了。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
| watch(()=>formData.value.enableSDK, v=>{
if (v !== oldData?.enableSDK && oldData?.enableSDK !== undefined){
sendFlag.value = true;
}
});
const openApiChange = (enableSDK: string) => {
if ((enableSDK === '0' && oldData?.enableSDK === '1')
|| (oldData?.enableSDK === '0' && sendFlag.value && enableSDK === '0')){
let modal = useModal(tr('sysCfg.mail.mail-title'), {
title: tr('sysCfg.mail.confirm_title'),
width: MODAL_SIZE_MAP.md,
icon: 'confirm',
autoDestroy:true,
submit: () => {
formData.value.enableSDK = '0';
modal.hide();
},
cancel: () => {
formData.value.enableSDK = '1';
modal.hide();
}
});
modal.open();
}
|
咋一看没啥问题哈，很不错，但大有优化空间，预期判定触发有几种条件，不如判定触发的共性！
说白了就是当处于禁用的时候触发嘛，那就优化！！
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| const openApiChange = (enableSDK: string) => {
if (enableSDK === '1' || isInit) {
return
}
const modal = useModal({
submit: () => {
modal.hide()
},
cancel: () => {
formData.value.enableSDK = '1'
modal.hide()
},
})
modal.open()
}
|
这次我们直接判定为触发的条件，然后退出，剩下的就是要触发的了。
首先第一种情况，就是判断当前是启用状态，或者第二种是获取数据失败的（定义个初始值为 true 的判断变量，当初次加载成功获取接口数据时置为 false），这两都退出，剩下的就爆弹窗，甚至可以把确定按钮的赋值操作省去，简单明了。
持续学习吧，去成为想成为的人，去想去的地方
