实际开发中遇到的一些小优化（sangfor篇-下）

携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第23天，点击查看活动详情

小记录下在公司实际项目中遇到的bug或小优化吧，优化点一般是导师初审的时候指出，或在代码合并的时候组员review指出，小改一波，较于之前有更好的可读性与维护性。

查找元素优化

注释的写法太小白了，我要找的就是所选数组下标，为此专门写了个所有key的数组，在通过传入的key在这数组查找，在比对，饶了一大远路，忘记了findIndex方法，这波是忘记专门的API，拿到需求直接上手开造造成的逻辑缺陷。

    // 1.根据传入的id找到当前行的数据
    const rowIndex = newGridData.findIndex(item => item.trapAddr === id);
    // 2.判断当前修改数据的id是否存在于旧数据中
    const sameIndex = newGridData.findIndex(item => item.trapAddr === data.trapAddr);
    if (sameIndex !== -1){
        fail(tr('snmpOptMgt.edit'));
        return;
    }
    // 3.修改
    newGridData[rowIndex] = data;
    isSend = true;

    // newGridData.forEach((value, index) => {
    //     // 定义一个表格所有数据key的数组
    //     const trapArray = newGridData.map(item => item.trapAddr);
    //     // 查找trapAddr,存在就返回数值没有返回undefined
    //     let same = trapArray.find(value => value == data.trapAddr);
    //     // 如果选中行的地址和原始数据的地址不同就退出
    //     if (value.trapAddr !== id) {
    //         return;
    //     }
    //     // 如果修改的地址存在原始数据中就退出
    //     if (data.trapAddr !== id && typeof same !== 'undefined') {

    //     }
    //     newGridData[index] = data;
    //     isSend = true;
    // });

radio选择优化

有这么个条情况，两个radio的item项，有个change事件，只在由启用变为禁用的时候，才会触发确认弹框。

于是我我把那两种情况写了个遍，由启用变为禁用，或者初始值为禁用，更改后（还写了变量判定）提交值变为禁用，才触发，很不错啊，思路很清晰。但这条件一判定下来，就又臭又长了。

watch(()=>formData.value.enableSDK, v=>{
    // 判断radio是否修改
    if (v !== oldData?.enableSDK && oldData?.enableSDK !== undefined){
        sendFlag.value = true;
    }
});

const openApiChange = (enableSDK: string) => {
    // 启用：1，禁用：0
    // 进入判断的两种情况：由启用更改为禁用;由禁用改为启用在禁用
    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();
    }

咋一看没啥问题哈，很不错，但大有优化空间，预期判定触发有几种条件，不如判定触发的共性！

说白了就是当处于禁用的时候触发嘛，那就优化！！

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），这两都退出，剩下的就爆弹窗，甚至可以把确定按钮的赋值操作省去，简单明了。

持续更新中...

去成为想成为的人吧，去想去的地方吧