I prefer angular-redux, as it feels like the effects are just a lot more overhead as opposed to say async action creators in a service with redux. I know the reasons why, but I absolutely prefer a more unidirectional event/data flow that I get with Redux, even in Angular.
Nothing really applies to angular. If you're developin your app separate from the api, your ouput will probably be straight JS.
If your app is deplying to doker, cool... otherwise you kind of loose the `npm ci` advantages. In the end it's more of an okay primer for docker than angular's use imho.
I like tests flattened into the same directory MyControl.test.js or .spec.js
Also, instead of a package.json, add an index.js re-exports the specific named control.js file... The practice in use may cause complications with build systems or future mjs references.
#2, might as well use an object... the "encode" is meaningless since it won't be a numeric comparison. may as well use `this["_" + word] = true;` prepending the underscore only to avoid use of reserved words, or overriding object prototypes.
#5 the linked list's "insert" doesn't account for middle-insert or changing current position.
Umn, there's no JSON involved at all... JSON is a string... this is an object selection library. I know it's nitpicking but I'm really sick of people calling all objects in JS "JSON".
Interesting writeup... There are some things that may feel weird... but in the end it makes sense when you're thinking of ETL and validation. In the case of the above, it's a garbage in/garbage out scenario... the fact that JS lets you do it is pretty awesome. JS is better than most at dealing with garbage and not blowing up. For it's first purpose, validating input, it's great. It also makes it great as a middle-tier service language as a result.
I have mixed feelings on this one... The first example removing comments is probably a poorer example, as I don't feel the latter is cleaner.
Not having TODO's is heavily arguable, I'd go so far as to say *DO* add todo, but reference a backlog/issue number related to the issue/pbi you create to refactor the TODO item.
// TODO #803 - Break off into separate module and refactor
I completely agree with exit early... as to one of the rebuttal comments on complex returns... then break it up into smaller chunks of independent functions.
I have mixed feelings on this one... The first example removing comments is probably a poorer example, as I don't feel the latter is cleaner. Not having TODO's is heavily arguable, I'd go so far as to say *DO* add todo, but reference a backlog/issue number related to the issue/pbi you create to refactor the TODO item. // TODO #803 - Break off into separate module and refactor I completely agree with exit early... as to one of the rebuttal comments on complex returns... then break it up into smaller chunks of independent functions.