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.
Interesting work.. the MS one may be work in terms of checking build/install against windows... possibly work towards pre-build dist for binary modules. There are quite a few popular modules that are still require gyp/build tools setup. This is problematic in some (windows) scenarios.
Sorry, but I prefer feature based structure... dividing by file type only makes it harder to work on a given feature as you're scrolling across your project looking for the different parts.
Interesting review... another issue with keeping these things in Node, is memory usage... Node really does constrict you on memory usage, to the point you probably don't benefit from a 64-bit version, unless you env is 64-it only which requires it.
Redis is as valuable as extended memory storage as it is a pub/sub.
Angular 2's RTM should have just been Angular 3, that bump would have provided a lot of protection against dated blog articles and documentation out in the wild.
From there, a progressive growth via semver would have been nice with LTS breaks, similar to node and/or React.
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.