从个人使用经历来看, whistle 的配置语法经常 不符合直觉
.
一方面是正则的匹配模式太难记, 每次过 2 天必忘, 虽然语法是简洁了, 但是实际使用效率极低.
另一方面, 有些规则仅在特定条件下可用, 比如resReplace
, 仅在 200 响应时会生效. 先不探讨这里面的具体设计出发点, 实际使用时这种 case 真的极难 debug 确认究竟为什么我的规则不生效.
思考了一下, 我想探索有没有可能设计一种更优的配置语法, 在简洁高效的同时, 易懂, 符合直觉, 且可以 debug.
简单给出了以下一个 demo 版本, 供大家讨论.
整体设计上保留 whistle 的 pattern: rule
规则, 使用()
来容纳匹配规则, {}
来容纳匹配之后的各种操作.
具体格式表现为(filter) {...operations;}
.
filter
可以放置多组规则, 表现为method:params
形式. 每个规则名对应到实现上可以是一个个独立的function call
.
比如(method:get, url:a.b.c)
意为限定method
是 get 请求, 且 url 域名为a.b. c
的请求
同时保留了 whistle 可以声明 data 的特性, 允许直接创建 custom method, 并在匹配规则里使用. 可以参考下方的 demo. 使用的时候可以通过|
符号来要求注入一些关键信息, header
responseBody
等等.
匹配之后的操作类似, 在{}
内部声明你的 operation, 多个 operations 使用;
隔开.
比如{url:localhost:8080}
表明需要将命中的请求, 转发到localhost:8080
这个地址.
```js
function listenMsg() {
window.on('message', evt => console.log(evt.data))
} ```
```js
function withCodeOk(header, body) {
if (body?.code === 'ok') return true;
}
```
```mock.json
{
"code": -1,
"message": "test non-ok code"
} ```
// (filter) { ...operations; }
(url:a.b.c) { url:127.0.0.1:8000 } (url:code.github.com/:path1) { url:trap.mock.com/$path1 } (url:code.github.com/?name=) { url:trap.mock.com/$[1]?rename=$[2] }
(
method:post,
url:*://a.b.c/api,
header:content-type=application/json,
withCodeOk:header|body
) {
resBody:mock.json;
resStatus:400
}