JS 代理模式实践

背景

最近在工作中遇到了需要对Module中导出的方法统一做预处理,在特殊场景下需要增加阻断执行并提示开发者不应该在该场景中使用该方法的提示。

思考

这里一开始的想法其实是在每个方法的入口分别增加一个阻断的判断逻辑:

如果只有一两个方法其实这么做倒还好,但现在的问题是,我手上有30多个方法都要加这个阻断逻辑,手搓阻断逻辑实在是太傻逼了,这么加不知道得加到猴年马月去。

后面我又看到Module的export default,想着能不能在这里做一下文章。

研究了一下之后,其实还是可以搞的,大致思路如下:

在ES6中,javascript引入了代理函数,从而实现对象基本操作的拦截和自定义(如属性查找、赋值、枚举、函数调用等)[1]。通过利用其拦截的特性,我们可以借此在module上实现代理模式。在外部函数获取method的时候做一些特殊逻辑。

实现

通过该方法,我们可以优雅的在module层面对method进行统一的前置操作(比如数据上报、逻辑阻断等操作),提升开发效率的同时还能使得代码更加简洁易维护。

兼容性

通过查阅caniuse,可以说这个接口已经100%兼容可用了。另外由于ES5的特殊性,Proxy是没有完整支持的polyfill的,因此如果碰到实在不兼容的用户,就积极引导用户去升级机器吧,没必要去钻这个牛角尖。

Android外网基本上只有电视盒子还是在4.4.4,手机几乎找不到4.0的机器,就算有看着0.08%的用户占比感觉可以直接忽略了。

作者: 7gugu

I'm a phper!

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注