yuan
·

关于 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.

bookmark_add
添加收藏
评论
登录后评论

当接收到一个代表错误的 HTTP 状态码时,从 fetch() 返回的 Promise 不会被标记为 reject,即使响应的 HTTP 状态码是 404 或 500。相反,它会将 Promise 状态标记为 resolve(如果响应的 HTTP 状态码不在 200 - 299 的范围内,则设置 resolve 返回值的 ok 属性为 false),仅当网络故障时或请求被阻止时,才会标记为 reject。

太 TM 对了。

reply
回复
社区准则 博客 联系 反馈 状态
主题