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.
Regarding the "uncaughtException", I will usually put enough to log the error as a fatal error to the logger, wait 100ms (for logger to flush) and process.exit(666) ...
Regarding custom net server implementation... JSON.stringify will, by default wind up on one escaped line, you can then use newline (\n) termination for requests and responses, making it quite a bit easier to dynamically extend for future use, as well as being able to stream input/output compared to other multi-line requests and termination.
Did not know about the repl .load, very cool.
Nice work on pulling this together... There seem to be some work towards Ubuntu and Windows (UWP) React Native applications as targets as well.
As an alternative, one could also use React proper with electron and/or cordova for platform specific targets and share more codebase. Depending on your app, this may be a better choice.
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.