如何写好业务代码？
在前端工作中有很多业务性代码，如果书写不规范，那么对后期的维护将是非常致命的。

判断配置化

业务场景

后端数据库中经常会一个字段具备几个不同的状态，比如：

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.jsexport const cfg = new Map([    [0, 出生],    [1, 儿童],    [2, 少年],    ... ... ]);// 业务代码cfg.get(status)

但是这样仅仅是显示相关的状态，如果涉及到状态的判断，那这样的处理方式就有些问题了，比如需要根据具体的状态去做对应的判断

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

像上面的情况，又变成了第一种情况，显然这种配置化的方式并不能满足。如果将对应的操作，与配置分割，则代码更加不易维护。

方法三（升级配置文件，处理代码集中）（better）

将状态处理集中起来，如果能将状态展示和对应的状态封装起来，那么就会让后期代码维护显得十分集中。

// cfg.jsconst 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>    );}// Onefunction One({isShow}) {    return (        <Fragment>            {                isShow === true                ? (                    <div>123</div>                )                : null            }        </Fragment>    );}// Twofunction 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中使用高阶组件，因为高阶组件每次返回来的都是新的组件，会使子组件的状态丢失。但是在无状态组件中，这样使用并没有什么问题，因为无状态组件本身就是随参数的变化而变化的，只是可能会产生性能问题。

总结

前端配置化的整体思路：

针对不同值进行不同处理的时候，思考一下，是不是可以将判断逻辑代码集中起来。
针对组件的显示/隐藏，可以将具体的隐藏逻辑封装为高阶组件，便于维护