怎样写好营业代码？
在前端事情中有许多营业性代码，假如誊写不范例，那末对后期的保护将是异常致命的。

推断设置化

营业场景

后端数据库中常常会一个字段具有几个差别的状况，比方：

status: 2
// 各个字段对应的寄义
0: 诞生
1: 儿童
2: 少年
3: 中年
4: 老年

• 如许差别的数字代表的寄义，须要在前端展现。
• 须要依据差别的状况，前端去做差别的处置惩罚

要领一（switch）（bad）

下面这段代码就是罕见的无穷if/else或许switch场景

// 营业代码
switch (status) {
    case 0: 
        // do something
        return '诞生';
    case 1:
        // do something
        return '儿童';
    ... ...
    default:
        return '';
}

如许做是不好的，由于假如后端再加了一个字段，比方

5: 已殒命

那末前端须要从新修正switch函数，如许须要去修正对应的营业函数，无疑破坏了营业代码的完整性。

要领二（写成设置文件）（better）

// cfg.js
export const cfg = new Map([
    [0, 诞生],
    [1, 儿童],
    [2, 少年],
    ... ... 
]);

// 营业代码
cfg.get(status)

然则如许仅仅是显现相干的状况，假如涉及到状况的推断，那如许的处置惩罚体式格局就有些题目了，比方须要依据详细的状况去做对应的推断

switch (status) {
    case 0:
        // do something
        return ;
    ... ...

}

像上面的状况，又变成了第一种状况，明显这类设置化的体式格局并不能满足。假如将对应的操纵，与设置支解，则代码越发不容易保护。

要领三（晋级设置文件，处置惩罚代码集合）（better）

将状况处置惩罚集合起来，假如能将状况展现和对应的状况封装起来，那末就会让后期代码保护显得非常集合。

// cfg.js
const status = new Map([
    [0, 诞生],
    [1, 儿童],
    [2, 少年],
    ... ... 
]);
const checkIsBirth = (status, callback) => {
    if(status === 0) {
        callback && callback()
    }
}
export default {
    status,
    checkIsBirth
}
// 在详细运用中
import Person from './cfg.js'
const a = 1;
Person.status.get(a);
Person.checkIsBirth(a, () => {
    console.log('Person is in Birth state');
})

如许处置惩罚，假如今后status发生变化，只须要修正checkIsBirth中的推断逻辑就能够，只须要修改一处。

代码设置化

在运用react编写代码的过程当中，常常用到如许的状况，依据状况推断是不是展现对应的组件。

要领一（流水线事情）（bad）

function Business({status, bug}) {
    return (
        <Fragment>
            {
                status === 0
                    ? (
                        <div>123</div>
                    )
                    : null
            }
            {
                bug === 1
                    ? (
                        <div>456</div>
                    )
                    : null
            }
        </Fragment>
    );
}

如许的写法假如仅仅只要一个实在还好，假如有许多个，在代码中会构成代码异常冗杂，使设想一个页面中假如有许多如许的，代码看起来异常ugly。所以发起将代码支解开来，构成一个个小的组件，将对应的代码封装起来，将会使代码可读性进步一些。

要领二（组件粒度细化）（better）

function Business() {
    return (
        <Fragment>
            <One isShow={status === 0} />
            <One isShow={bug === 1} />
        </Fragment>
    );
}

// One
function One({isShow}) {
    return (
        <Fragment>
            {
                isShow === true
                ? (
                    <div>123</div>
                )
                : null
            }
        </Fragment>
    );
}

// Two
function Two({isShow}) {
    return (
        <Fragment>
            {
                isShow === true
                ? (
                    <div>456</div>
                )
                : null
            }
        </Fragment>
    );
}

假如常常这么写是不是是会以为很烦，能够将通用的逻辑笼统为通用的组件。

要领三（高阶组件）（better）

实在能够张望一下decorator今后的用法,临时没有找到运用的切入点。

function IsShowCom(isShow, Wrapped) {
    if (isShow === true) {
        return (Wrapped) => <Wrapped />
    }
    return () => null;
}
// 假如你想转发ref，你得这么做
function IsShowCom(isShow, Wrapped) {
    if (isShow === true) {
        return React.forwardRef((props, ref) => {
            return <Wrapped {...props} ref={ref} /> 
        });
    }
    return () => null;
}
// 
import IsShowCom from './isShowCom';

function Business() {
    const One = IsShowCom(
        status === 0,
        <div>
            123
        </div>
    );
    const Two = IsShowCom(
        bug === 1,
        <div>
            456
        </div>
    );
    return (
        <Fragment>
            <One/>
            <Two/>
        </Fragment>
    );
}

注重⚠️

不要在render中运用高阶组件，由于高阶组件每次返返来的都是新的组件，会使子组件的状况丧失 。然则在无状况组件中，如许运用并没有什么题目，由于无状况组件自身就是随参数的变化而变化的，只是可能会发生机能题目。

总结

前端设置化的团体思绪：

• 针对差别值举行差别处置惩罚的时刻，思索一下，是不是是能够将推断逻辑代码集合起来。
• 针对组件的显现/隐蔽，能够将详细的隐蔽逻辑封装为高阶组件，便于保护