I keep thinking that a lot of the additional methods that bluebird offers should be added to Promise for esNext...
On the flip side, Promise is available in all modern browsers, so it may be better to keep to the standard API.
The first code sample has a lot of unneeded redundancy to begin with. Also... `this.foo()` is not more readable than `foo()` and you're creating an object context for no value add and complicating testing.
semi-related... here's a quickie one-off app I wrote to snag the geodata off of an image in order to process/tag photos[1]. It wasn't hard at all to grab the geolocation from camera images that add it.
It's doing the data capture server-side in a React application using the exif package[2]. If I did it again, might have taken the extra time to make it into a full electron based application, instead of requiring a local node server. Worked for the needs in place though.
[1] https://github.com/tracker1/azt-photo-app
[2] https://github.com/tracker1/azt-photo-app/blob/master/lib/photo-location.js#L28
Basically Promise.all const myItems = await Promise.all(itemIds.map(async (itemId) => { return await myService.getItemByItemId(itemId); }));semi-related... here's a quickie one-off app I wrote to snag the geodata off of an image in order to process/tag photos[1]. It wasn't hard at all to grab the geolocation from camera images that add it. It's doing the data capture server-side in a React application using the exif package[2]. If I did it again, might have taken the extra time to make it into a full electron based application, instead of requiring a local node server. Worked for the needs in place though. [1] https://github.com/tracker1/azt-photo-app [2] https://github.com/tracker1/azt-photo-app/blob/master/lib/photo-location.js#L28