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
You can start here:
http://marmelab.com/blog/2015/12/17/react-directory-structure.html
I may go multiple levels deep, but in essence it's about keeping structure based on the feature/section you're working on. Not every feature will contain controls and/or other models. Some may be one or the other.
In this way, you are less likely to need to scroll back and forth to keep your smart and dumb components and/or reducers etc in your project, as related items should be in proximity.
The same goes for tests... the .(test|spec).js file should be right next to the .js file... It serves nobody to have to trek through several layers of identical directory structure to get to them.
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#L28You can start here: http://marmelab.com/blog/2015/12/17/react-directory-structure.html I may go multiple levels deep, but in essence it's about keeping structure based on the feature/section you're working on. Not every feature will contain controls and/or other models. Some may be one or the other. In this way, you are less likely to need to scroll back and forth to keep your smart and dumb components and/or reducers etc in your project, as related items should be in proximity. The same goes for tests... the .(test|spec).js file should be right next to the .js file... It serves nobody to have to trek through several layers of identical directory structure to get to them.