前端业务代码配置化

时间: 2019-06-09阅读: 193标签: 代码

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


判断配置化

业务场景

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

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


总结

前端配置化的整体思路:

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

原文来自:https://segmentfault.com/a/1190000019420857


链接: http://www.fly63.com/article/detial/3606

TypeScript 来做依赖注入的限制

依赖注入 是编写可测试/复用代码的关键。 在 TypeScript 中所有对象、属性和方法都有类型,可以大幅简化人工标注的代码,这让很多人重新考虑在 JavaScript 中实现依赖注入。 比如 Angular2 以后的 DI 实现

后端传过来一个JS代码,前端拿到之后执行

今天收到了一个需求,居然是后端给我传过来一个JS代码,然后前端去执行。因为后端传过来的JS代码是一个字符串,所以刚开始有点懵,以前也没有做过这样的东西所以刚开始没有方法。

Js代码中的span拼接

今天遇到一个小需求,用bootstrap的table只有两个字段,占用太宽,页面不美观,组长要求用拼接,一行几列的形式展现出来。我在form表单中拼接了span,遇到以下问题:

怎么样才能不写出别人嘴里的烂代码?

每个人对于好的代码在自己不同的时期都有不一样的理解。当个人所在的层次变化,好代码的概念也会跟着变化。老夫上手就是复制粘贴,别跟我说什么编码规范,设计模式。

你不知道的 useCallback

对于新手来说,没写过几次死循环的代码都不好意思说自己用过 React Hooks。本文将以useCallback为切入点,谈谈几个 hook 的使用场景,以及性能优化的一些思考。

写业务代码最容易掉的8种坑

线程、线程同步、池、网络连接、网络链路、对象实例化、内存等方面的基础是最容易犯错的地方,搞清楚框架内部对于这些基础资源的的使用方式,根据最佳实践进行合理配置,这是业务开发时需要特别关注的点。

如何用不到200行代码写一款属于自己的JS类库

JavaScript 的核心是支持面向对象的,同时它也提供了强大灵活的 OOP 语言能力。本文将使用面向对象的方式,来教大家用原生js写出一个类似jQuery这样的类库。我们将会学到如下知识点

Js代码整洁之道

最近在做一些项目重构的工作,看了不少脏乱差的代码,身心疲惫。本文将讨论如何编写整洁的代码,不求高效运行,只求可读性强,便于维护。

什么样的代码叫好代码?

代码的本质还要在机器上运行,好的代码不单单的纯粹的简单的几个字符的问题,好的代码不仅仅是排版上或者语法上好看,还要能经过产品的测试验证,这是评判代码好坏的最准确的标准

程序员该如在低代码和无代码开发中抉择?

对于一个人第一次是如何了解低代码/无代码这两种开发方式,我总是充满好奇。这就是为什么我觉得贸易展会是如此有趣的原因;因为我可以拿同样的问题问每一个走进你的展台的人们。通常这是我问他们的第一个问题,当然是在扫描了他们的胸牌之后。

fly63.com版权所有,内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权,请与小编联系!情况属实本人将予以删除!

广告赞助文章投稿关于web前端网站点搜索站长推荐网站地图站长QQ:522607023

小程序专栏: 土味情话心理测试脑筋急转弯幽默笑话段子句子语录成语大全