用过类似 whistle 的朋友 讨论看看有没有更好的配置语法

背景

从个人使用经历来看, 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

}