fetch与promise.finally

es7里面的Promise.prototype.finally,可以通过core-js的polyfill来补全。

本以为加上了core-js就可以了,但真的遇到不支持的浏览器仍然会报没有finally方法的错误。

打开控制台调试,发现Promise.prototype.finally已经打上补丁是存在的。

最后发现,在chrome中

const f = fetch()
f instance of Promise // true

在火狐的低版本浏览器中

const f = fetch()
f instance of Promise // false

 

fetch返回的是个伪Promise对象,并不是全局Promise的实例,怪不得没有finally方法。

干脆通过自己加上一段代码polyfill上去得了

;(function() {
  const f = fetch()
  if (f.__proto__ && !f.__proto__.finally) {
    f.__proto__.finally = function(callback) {
      return this.then(callback).catch(callback)
    }
  }
})()
发表在 ecmascript | 留下评论

后端对于restful接口返回状态码的理解

今天在上班路上突然理解了一件长久以来困扰我的事情。

做前端这几年,遇到做后端的接口,全都声称是restful接口,但使用http状态码作为判定条件的一个都没有,统统返回200然后在消息体里自定义状态码。

原因大概因为jquery或axios等接口请求库,默认配置下,接口若返回非200响应,里面的消息体就拿不到啦。在大部分人的前端知识体系中,非200意味着抛出错误,消息体什么的当然拿不到,所以当应用出错时希望拿到错误提示等信息,必须还是返回200的状态。

其实,非200的状态返回的消息,前端一样拿得到,只是需要一些额外配置一下。但后端人员对于前端jquery ajax请求应用的示例作为标准,或者理所当然认为前端人员的水平也只能获取到200返回的消息。于是就出现了各种各样的自定义消息体…

推荐一下fetch,返回的是Response对象,只要是服务端相应了,里面都可以拿到各种接口返回数据,只有在网络出问题比如请求不可达的情况下会抛出错误。

最后为自己的库做个广告 fxios

发表在 ecmascript | 留下评论

deno与typescript

多年前用过coffeescript,后来换工作之后因为团队里没人用,被强制放弃了。也幸亏放弃了coffeescript,才能紧跟ecmascript语法的发展,之后就一直用babel走标准es语法路线,在选择编译型前端(类似coffee需要编译成js才能运行)语言的时候都非常谨慎。

之前我在flowtype与typescript之间一直倾向flowtype,一点是因为是facebook出品和react是一家,另一点是因为flowtype允许渐进式引入项目。typescript则是一旦使用则必须全部使用,至于是微软出品倒是不太介意。

最近node的作者新开了个deno,默认直接运行typescript,node一下成了没爹的娃,可持续性堪忧。最重要的一点是:typescript赢了,各位准备深入学习吧。已经提早入ts坑的同学们,恭喜路子走对了。

发表在 ecmascript | 留下评论