前端业务代码配置化

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

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


判断配置化

业务场景

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

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


吐血推荐

1.站长广告联盟: 整理了目前主流的广告联盟平台,如果你有流量,可以作为参考选择适合你的平台点击进入...

2.休闲娱乐: 直播/交友    优惠券领取   网页游戏   H5游戏

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

如何阅读别人的代码?

比起阅读代码,我更喜欢看别人的文章或者书。我喜欢他们跟我面对面的交流,用简单的自然语言或者画图解释他们的思想。有了思想,我自然知道如何把它变成代码,而且是优雅的代码

把同事的代码重写得干净又整洁,老板却让我做回滚?

我的同事把这周写的代码提交了。我们在开发一个图形编辑器画布,已经实现了形状调整功能,即通过拖拽形状边缘的手柄来调整形状(比如矩形和椭圆形)。代码可以运行。

掌握依赖注入5大原则,无需额外编代码!

如果是第一次接触这个概念,可能会一时没有头绪,网上的各种解释可能会让你更加混乱,并觉得它没那么简单。 其实依赖注入本身是单纯、简单的。简单来说,依赖注入是一种方式、方法或者说手段

如何在 React 中优雅的写 CSS?

如果是 ui 组件库中使用建议使用 namespaces 方案,ui 组件库维护人员基本固定,遵守约定的规范较为容易,可通过约定规范来解决不同组件 CSS 相互影响问题,由于 ui 组件库会应用于整个公司的产品

让代码具有可读性的10种最佳实践

如果咱们关注代码本身结构及可读笥,而不是只关心它是否能工作,那么咱们写代码是有一定的水准。专业开发人员将为未来的自己和“其他人”编写代码,而不仅仅只编写能应付当前工作的代码。

如何执行innerHtml中的script代码?

有时候我们会有把一整段 HTML 动态塞进页面的需求,例如渲染了一个模板,从服务器端获取了一段广告代码等。一般情况下我们使用 container.innerHTML 即可

编写可维护的Js代码

不省略分号(在原生及使用工具函数的情况不建议省略,在使用比较完善的框架如vue或者自己配置好 webpack 时可以省略),1行代码长度不超过80个字符(个人比较推荐,毕竟编辑器的自动换行有时真的很难受)

200行代码实现超轻量级编译器

本篇和大家一起学习写一款超级简单轻量,去掉注释只有不到200行代码的编译器。,该编译器将类 lisp 语法函数调用 编译为 类C语言函数调用

什么才是优秀的代码?

究竟什么是优秀的代码?Robert Martin的一句话可以完美诠释。代码质量的唯一衡量标准是每分钟说多少次WTF,我来解释一下这句话。当我在做code review时,通常会有三种不同的感受:

好代码的用处,怎么写出好代码?

实际上本书建立在一个相当不可靠的前提之上:好的代码是有意义的。我见过太多丑陋的代码给他们的主人赚着大把钞票,所以在我看来,软件要取得商业成功或者广泛使用

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

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

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