从个人使用经历来看, 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这个地址.
Demo
```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
}
