5 ms·
Node.js 7.6 Released
- roryrjb 10y agoSo this, having V8 5.5 means async await is now stable and available without command line flags? Awesome!
- roryrjb 10y agoA short V8 5.5 feature overview: https://v8project.blogspot.nl/2016/10/v8-release-55.html https://v8project.blogspot.nl/2016/10/v8-release-55.html
- tracker1 10y agoThanks... may have to take the time to have a couple different webpack configs so I can target the latest chrome (and edge 15, safari 10.1, etc), separately from the es2015 builds. It's been coming for a while, but finally getting browsers that don't need nearly as much fluffy goodness from babel, which I'm happy to see.
- nailer 10y agoYummy. No .then() chaining, no async.waterfall(), no pyramid. Not totally seamless as parent scope has to be run with `async` but still excellent: async function logFetch(url) { try { const response = await fetch(url); console.log(await response.text()); } catch (err) { console.log('fetch failed', err); } }
- always_good 10y agoHere's my attempt at a slightly less contrived example: router.get('/users/:id', async (ctx, next) => { const user = await db.getUser(ctx.params.id) if (!user) return ctx.send(404) let data if (user.admin) data = await api.getSomeData(user) return ctx.render('show_user.html', { user, data }) })
- yamalight 10y agoThis would quietly swallow all the errors though
- always_good 10y agoThat's actually one of the whole points of using promises: it doesn't swallow errors. Errors bubble up to the top-level. It's the old callback-style that swallows errors unless you manually handle them every time. It's one of the chief advantages of promises. In my case, errors bubble up to error-catching middleware and, at the end of the chain, into a 500 error that gets logged.
- yamalight 10y agoThe errors won't be swallowed only in two cases: either if router.get actually supports promises (thus catches all the bubbled errors on its own) or if you have unhandledRejection global listener. Some node versions do show unhandled rejections automatically (e.g. v7.x), but that is getting deprecated soon. So, there's quite a real risk of quiet failures in that bit of code. Upd. Looks like even though the unhandled rejections warnings are getting deprecated, the rejections themselves will actually stop the code execution with non-zero exit code! Which means most of the issues I had with that code are gone (which is awesome)
- deleted 10y ago[deleted]
- deleted 10y ago[deleted]
- always_good 10y agoOf course the code in my example handles promises. It's actually an example of koa code. Not sure why that is a "real risk". You generally want to be using promises with libraries that support them. That's why I wouldn't use promises in vanilla Express as my daily driver abstraction. Compare this to callbacks where there's an actual real risk of silent error dropping any time you forget to `next(err)` or `.catch(handleErr)`, which is something you have to carry around for the life of the project instead of my example, where you choose a framework (once) that supports them. I'd say it's a great demo and addressed all your concerns so far since it's this kind of context where async/await really pays off compared to the logFetch example.
- ralusek 10y agoI so much prefer promise syntax to this, I do not understand why people favor this at all.
- cocochanel 10y agoMuch easier to read and understand. Same scope. No chains and chains of nested messiness.
- brad0 10y ago> fs: allow WHATWG URL objects as paths (James M Snell) Can someone explain this to me? Does this just mean I can open files using the 'file:' syntax or can I somehow open URLs with readFile now?
- SlashmanX 10y agoThe linked PR[0] says it's just using the file: syntax [0] - https://github.com/nodejs/node/pull/10739 https://github.com/nodejs/node/pull/10739