欢迎访问 生活随笔!

生活随笔

当前位置: 首页 > 编程资源 > 编程问答 >内容正文

编程问答

业务代码配置化

发布时间:2025/4/16 编程问答 32 豆豆
生活随笔 收集整理的这篇文章主要介绍了 业务代码配置化 小编觉得挺不错的,现在分享给大家,帮大家做个参考.

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

判断配置化

业务场景

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

status: 2 // 各个字段对应的含义 0: 出生 1: 儿童 2: 少年 3: 中年 4: 老年 复制代码
  • 这样不同的数字代表的含义,需要在前端展示。
  • 需要根据不同的状态,前端去做不同的处理

方法一(switch)(bad)

下面这段代码就是常见的无限if/else或者switch场景

// 业务代码 switch (status) {case 0: // do somethingreturn '出生';case 1:// do somethingreturn '儿童';... ...default:return ''; } 复制代码

这样做是不好的,因为如果后端再加了一个字段,比如

5: 已死亡 复制代码

那么前端需要重新修改switch函数,这样需要去修改对应的业务函数,无疑破坏了业务代码的完整性。

方法二(写成配置文件)(better)

// cfg.js export const cfg = new Map([[0, 出生],[1, 儿童],[2, 少年],... ... ]);// 业务代码 cfg.get(status) 复制代码

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

switch (status) {case 0:// do somethingreturn ;... ...} 复制代码

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

方法三(升级配置文件,处理代码集中)(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中使用高阶组件,因为高阶组件每次返回来的都是新的组件,会使子组件的状态丢失 。但是在无状态组件中,这样使用并没有什么问题,因为无状态组件本身就是随参数的变化而变化的,只是可能会产生性能问题。

总结

前端配置化的整体思路:

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

转载于:https://juejin.im/post/5cfbcff051882555f4465fac

总结

以上是生活随笔为你收集整理的业务代码配置化的全部内容,希望文章能够帮你解决所遇到的问题。

如果觉得生活随笔网站内容还不错,欢迎将生活随笔推荐给好友。