4 ms·
Instead of subtle nesting, I would have passed through the user as part of the result of the second promise. get('//data.com/user) .then(user => reso
by fooey 7y ago
Instead of subtle nesting, I would have passed through the user as part of the result of the second promise.
get('//data.com/user)
.then(user => resolve({user, location: get('//data.com/user')}))
.then(({user, location}) => createEntry(user, location))
.then(response => {
// handle response
}).catch(err => {
// handle failure
});
Async/await is much cleaner now though.
- korla 7y agoHow does the resolve function work here? It is passed an object where one property is an object and the other a promise. The next then suddenly receives the resolved location..?
- deleted 7y ago[deleted]
- hoorayimhelping 7y agoThe argument passed to `resolve` gets returned from the resolve function and becomes available to any handler that handles it with `then`. In the above example, the object is being destructured as part of the arguments. The destructuring is probably what's tripping you up. // straightforward, no magic const simpleFunction = function() { return Promise.resolve({ name: 'simpleObject' }); } simpleFunction().then(function(response) { console.log(response); // { name: 'simpleObject' } }); // alternatively, destructuring the arguments simpleFunction().then(function({ name }) { console.log(name); // 'simpleObject' });
- deleted 7y ago[deleted]
- korla 7y agoNo that is not what is tripping me up, or happening. The other answer explained it, some library code was executed aeaiting the location-promise.
- thedufer 7y agoIt iterates over all key/value pairs. For each value, if it is a promise it waits for it and replaces it with the result, while non-promises are left as-is. This is a fairly common function to have in promise libraries.
- korla 7y agoThat was my point. It’s not obvious to the reader that this is better since it’s a non-standard way of resolving promises. But it looks neat. I’ve never seen it, what library do you have experience with that does it this way?
- thedufer 7y agoI've been out of the JavaScript world for years now, but I last used Bluebird which has Promise.props[1] with this behavior. [1] http://bluebirdjs.com/docs/api/promise.props.html http://bluebirdjs.com/docs/api/promise.props.html
- matt-attack 7y agoI affably don’t know how anyone considers the .then syntax to be any better than the original callback hell version. Especially if you want your error handlers to be unique and to affect the flow. Sorry but the common shared catch at the end doesn’t usually suffice in the code I write. I find the async/await form he alludes to at the end to be the only form that improves upon the original callback version.
- stareatgoats 7y agoAgree. Async/await and promises get overly complex and riddled with conceptual challenges in anything but the most basic examples. I finally rolled my own async job queue library instead (using .then, granted). A few hundred loc, but conceptually clear, no callback hell, a tiny bit more verbose, but full control over error handling in each callback. Such a relief.
- franciscop 7y agoIt's not much more clear, but it is a standard, which has many advantages: - Learn how .then()/.catch() works once and it's the same for all libraries. - Can test against a common API. - Can combine operations easily like with Promise.all(), which was very difficult with callbacks. - Chaining is much better since you can return a promise within a promise, which allows for conditional promises. - No nesting/right shifting, keeping the structure flatter.
- matt-attack 7y agoasync/await has all of those same advantages plus more I believe (and I should add I agree with all of them).
- franciscop 7y agoAsync/await is syntax sugar on top of .then(); without the standardization of promises with .then(), async/await would have been A LOT harder to get cross projects. Ofc async/await is waaay better than .then(), but you were talking about async/await vs callbacks, and so my points :)