关于 MithrilJS 的 m.request()

m.request() 的 API 目前定义如下：

m.request({
  method: ...,
  url: ...,
  body: ...
})
.then(function(result) {
  // 2xx, 304 处理逻辑
})
.catch(functiuon(error) {
  // 其余状态码处理逻辑
})

该 API 在响应状态码为 2xx 和 304 时，返回给前端程序员的是后端传过来的 JSON, 响应状态码本身以及响应头等其它信息都被丢掉了。所有其它状态码被当作请求失败，返回给前端程序员的是一个 Error 对象，其中包含响应体本身和响应状态码。

可能多数情况下这不是问题，但是如果前端在接收到成功的响应时，需要根据不同的状态码做不同的处理，就完全没有办法。

照我的理解，响应不能粗暴地直接这么一分为二。300, 301, 302 该算成功还是失败？2xx 的状态码也有许多种，就算都归为成功，也还是需要客户端区别对待，还不如一开始就不分。4xx 和 5xx 虽然被分别定义为客户端和服务器端错误，但跟 2xx 一样，还有许多细分的状态。所以作为框架，干脆就别定义所谓的成功和失败，把这个定义留给框架的使用者。

也就是说，m.request() 在收到响应之后，应该直接把原始的 Response 对象（或者稍微封装一下必要的信息）通过 fulfilled 状态的 Promise 返回给程序员，无论是什么状态的响应。而不需要用到 rejected 状态的 Promise, 如下：

m.request({
  method: ...,
  url: ...,
  body: ...
})
.then(function(response) {
})

2022-08-01 补充：在 Mithril 中，m.request() 的调用会引起 Mithril 的界面重绘，fetch() 则不会。起初我认为把 fetch() 和 m.redraw() 的调用封装在一起就好了，但后来发现不可行，fetch() 方法返回一个 Promise, 简单的封装做不到保证让 m.redraw() 在最后一个 .then() 调用之后才执行。思来想去，还是放弃了 MithrilJS. 最近在研究 SolidJS.