阅读 261

Whistle系列之(三)Whistle之简单使用

终于到了whislte的正式使用环节了,上一节我们介绍了如何搭建本地的wistle环境,本节我们将结合几个常见的业务场景介绍如何在本地前端项目开发中使用whistle。

一、使用webpack devServer的项目

1.1 项目准备

如今,大部分的前端项目是以webpack的作为开发和构建工具进行项目开发。 我们将以这样一个最常见的场景,即webpack开启本地devServer进行开发和调试的方式,展示如何在这样的前端项目中结合使用whistle。

我们以一个create-react-app开启的项目为事例来进行展示。 首先,假定有一个以create-react-app新建的,名为my-app的前端项目

create-react-app my-app cd my-app npm run start 复制代码

会在浏览器中开启一个localhost:3000的tab,这是我们常见的一个本地前端开发的场景。



本地host的弊端

一般情况下,我们可以直接在localhost下进行本地的调试开发。 但是,但是基于localhost本地开发模式有不少局限性,前面的系列文章有具体分析过,概括来说:

  • 用户身份相关的部分功能,如登陆功能,cookie读取等对客户端的域名有限制,使用localhost这个host可能会遇到限制

  • 使用localhost进行本地开发,业务代码中可能需要进行一些额外的逻辑判断,如针对本地域名和线上域名做行为区分等

1.2 配置whistle

为了解决上述问题,根据我们的实践经验,本地开发时,通过线上真实域名访问本地前端项目,似乎是一种更加有效的开发方式。

假设我们这个本地项目的线上真实域名为 qq.ketang.com. 则我们的目标即是通过 qq.ketang.com 访问和调试本地的my-app前端项目。

下面我们将演示如何使用whistle实现这个目标操作。

  • 1.2.1 配置whistle规则

打开whsitle的规则配置地址 127.0.0.1:8899, 依次进行如下操作:

-> 选择Rules选项卡

-> 双击开启Default配置(其后方出现绿色的打勾即为开启成功)

-> 在右侧规则编辑面板中输入以下规则

qq.ketang.com/  http://127.0.0.1:3000/ 复制代码

-> 选择Save



  • 1.2.2 启用proxy

选择SwitchyOmega插件的proxy模式

随后,在浏览器中访问地址 https://qq.ketang.com, 就能成功访问到我们本地的my-app项目了。

现在,我们就可以用项目的线上地址来调试本地项目,而不用使用127.0.0.1:3000这样的本地地址了。





whislte做了什么

这其实是 whislte中的配置规则起了作用

qq.ketang.com/  http://127.0.0.1:3000/ 复制代码

这条规则将所有 qq.ketang.com/ 及其子路径下的请求 转发到了http://127.0.0.1:3000/

whistle的功能强大之一就是提供了各种模式的规则匹配以应对前端开发中的不同场景,上面这条 只是一条最简单的规则。

如果你想现在就对whistle的配置规则有个更全面和清晰的认识,可以参考以下链接:

Whistle配置方式

Whistle规则的模式匹配

即使你有没细细翻阅又或者没有很好地理解whistle的配置规则也没关系,下面我们将继续以这个项目为例,结合几个常见的开发场景,告诉开发者应该如何配置常见的whislte规则。

忽略子路径下的cgi接口转发

在我们的my-app项目中,如果项目中涉及到同域下子路径的后端接口,如 qq.ketang.com/cgi-proxy/xxxxx ,我们的初衷是cgi接口不需要转发,依然走线上即可。

但是如果按照目前的配置,该cgi接口也会被转发至本地的相应路径,这显然不是我们希望看到的结果。

# bad, 不是我们所希望的 # qq.ketang.com/cgi-proxy/xxxxx 也会转发至 http://127.0.0.1:3000/cgi-proxy/xxxx qq.ketang.com/  http://127.0.0.1:3000/ 复制代码

此处需要使用 excludeFilter规则

# good,使用excludeFilter规则, 路径匹配 # qq.ketang.com/cgi-proxy/ 及其子路径下的请求不会被转发至 http://127.0.0.1:3000/cgi-proxy/ qq.ketang.com/  http://127.0.0.1:3000/ excludeFilter://qq.ketang.com/cgi-proxy/ 复制代码

以上我们在excludeFilter里采取的是路径匹配,此外我们还可以采取通配符匹配或者正则匹配来实现这一功能

# also good, 使用excludeFilter规则, 通配符匹配 # qq.ketang.com/cgi-proxy/, qq.ketang.com/cgi-bin/ ... 这类的请求都不会被转发 qq.ketang.com/  http://127.0.0.1:3000/ excludeFilter://qq.ketang.com/cgi-* 复制代码
# also good, 使用excludeFilter规则, 正则匹配 # qq.ketang.com/cgi-proxy/, qq.ketang.com/cgi-bin/ ... 这类的请求都不会被转发 qq.ketang.com/  http://127.0.0.1:3000/ excludeFilter:///^\w+://qq\.ketang\.com/cgi-/ 复制代码

有读者可能会疑惑,为什么以上正则匹配中的//qq的 // 没有转义,这是因为在whistle内部实际上是调用了 new RegExp的方式进行构造正则,已经自动做了转义,如果不放心,那么写成 //qq 也可以。

关于模式匹配的具体规则可以参考官方文档

Whistle规则的模式匹配

特定cgi接口的mock

一个常见的场景是我们需要对某个cgi接口的返回数据进行改造以模拟前端的多种case,whistle有多种方式可以帮助开发者实现该功能。

假设有一个cgi接口路径为 /cgi-proxy/getMyName, 则本地mock的方式有

  • 以本地文件作为响应

# qq.ketang.com/cgi-proxy/getMyName 以本地的//User/dug/test/getMyName.json文件作为响应, qq.ketang.com/cgi-proxy/getMyName  file:///User/dug/data/getMyName.json 复制代码
  • 编辑在线文件作为响应

如果不想用本地文件,也可以直接用whistle提供的在线文本功能。 在whislte的配置界面中

-> 选择 “Values”

-> 点击 “Create”, 输入自定义的文件名(此处为ans.json)

-> 选中新建的文件,在右侧的编辑栏中输入作为响应的内容

# qq.ketang.com/cgi-proxy/getMyName 以Values面板中的ans.json作为响应 qq.ketang.com/cgi-proxy/getMyName  file://{ans.json} 复制代码



  • 使用xfile模式

xfile模式和上述的file模式功能基本一致,xfile和file的唯一区别是file找不到对应文件返回404,而xfile则是继续请求线上资源。

# xfile和file基本功能一致,只是若找不到对应文件,xfile将会继续请求线上资源 qq.ketang.com/cgi-proxy/getMyName  xfile://{ans.json} 复制代码

二、无构建工具的传统前端项目

不少老的项目由于种种原因没有使用构建工具来构建前端js,css等前端资源。对于这种项目,我们希望用本地的对应资源来进行开发和调试。

比如,在我们现在需要对一个老项目进行迭代,项目的线上域名为 qq.ketang.com, 这次改动主要涉及到以下两个文件

<!-- index.html --> ... <link rel="stylesheet" href="/assets/css/main.css" type="text/css"> ... <script src='assets/js/module/my.js'> 复制代码

在whislte中,我们需要配置规则

# 分别将线上的css和js的访问 指向本机的项目路径 qq.ketang.com/assets/css/ xfile:///User/myName/myWork/ketang_pro/assets/css/ qq.ketang.com/assets/js/  xfile:///User/myName/myWork/ketang_pro/assets/js/ 复制代码

之后,我们在浏览器访问 qq.ketang.com,其中对于 /assets/css//assets/js/ 路径下的请求将会以本地项目目录/User/myName/myWork/ketang_pro/assets/css/和        /User/myName/myWork/ketang_pro/assets/js/下的对应文件响应,接着我们就能在本地修改和调试项目代码了。

三、以插件支持特殊的需求场景

有一些特殊的应用场景,依靠whistle的基础功能可能无法实现。

但是,whistle支持自定义插件来拓展功能,同时社区也有一些插件的积累。

例如,假设项目中有一个combo的url请求为 http://i.cdn.com/??x.js,y.js,z.js(一个比较不常见的场景) 。通过社区的whistle.combo插件可以实现将combo url切割成数组 [x.js, y.js, z.js]并分别组合成 http://i.cdn.com/x.js, http://i.cdn.com/y.js, http://i.cdn.com/z.js

关于插件 whistle.combo 详见

whisle.combo

另外,这里有一份whistle的插件集合,可以在里面搜寻是否有满足自己需求的插件。

whislte插件列表

参考资料

本文结合几个常见的前端开发场景介绍了如何在自己的项目中简单配置whistle规则,想要对whistle的规则配置有更多的了解,可以参考以下资料

whislte.org

github/whislte

whislte作者的文章列表


下一篇文章我们将介绍如何生成whistle配置,以及怎样在团队开发中让其他成员迅速搭建项目的whistle配置。


作者:duginsea
链接:https://juejin.cn/post/6844904167408943111


文章分类
代码人生
文章标签
版权声明:本站是系统测试站点,无实际运营。本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 XXXXXXo@163.com 举报,一经查实,本站将立刻删除。
相关推荐