Here's an example:
// server/index.js
async function main(skip) {
if (skip) return;
... rest of main ...
}
main(!!module.parent).catch(console.error);
export default main;
module.parent exists when you require in a module, in this case index, say for testing... but not when you execute the module directly `node server/index` for example.
by wrapping your main logic in a function with a skip parameter, if you load the `./index.js` inside `index.test.js` it won't start your server process... in this way you can override whatever modules are used, and test that logic.
Not sure where the down vote came from, it's definitely one of the better universal layouts I've seen...
A few points, would add in jest and tests for everything... would wrap the main server entry point so that it only runs when `!module.parent` and can be fully tested.
Post only really explains how to do react in a more angular-like paradigm for development using MobX and TypeScript. I'll admit, it is more apples to apples than most ng v react articles.
All of that said, it's kind of pointless really. The Angular shops are mostly sold as an upgrade path from their existing Angular 1.x knowledge and entropy of the framework. Merits aside. And I'll agree that React + Redux + more is very different as an approach.
The bigger differences come in when you have a very large project. Now you have some weird web of stores, dependencies, and data flows. React + Redux will scale complexity at a much lower incline that with other paradigms such as the ones in the article. If all you have is a simple form, and a simple view, it's not a big deal. When you have hundreds of custom components, and data stretching through many data sources, it becomes harder.
Not to mention the effort to shoehorn a GraphQL reference into the mix.
It encourages sites to keep using a bad password validation scheme in place. A big readme pointing out that it's far better to have a complexity requirement and indicator than it is to have arbitrary password character requirements.
I don't think it was so much spam, but it did seem to cut off right at the part where I actually wanted more detail. I'd actually almost rather see an interview transcript, and wish the article had included it.
All of that said, this is definitely an article geared towards managers, not so much for developers, unless you're in a smaller shop and trying to champion change.
Here's an example: // server/index.js async function main(skip) { if (skip) return; ... rest of main ... } main(!!module.parent).catch(console.error); export default main; module.parent exists when you require in a module, in this case index, say for testing... but not when you execute the module directly `node server/index` for example. by wrapping your main logic in a function with a skip parameter, if you load the `./index.js` inside `index.test.js` it won't start your server process... in this way you can override whatever modules are used, and test that logic.*sigh* this falls into the same traps over and over again... See the following... [0] https://xkcd.com/936/ [1] https://github.com/dropbox/zxcvbn