#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 really don't like the "redux" name used in software that is so very different from redux, it doesn't even resemble the original anymore. Call it something else already, and stop trying to piggyback on the success of another open source software. Even if you are using redux underneath, this is emphatically *not* redux.
For what it's worth @angular-redux/store bugs me so much less than this.
Decent primer on ES6 class syntax.
1. Should use `TypeError` for the error message for an abstract class.
2. Missing class field declarations[0] (stage-3, but eminent).
class Foo {
bar = 'instance';
baz = () => console.log(`I'm context bound to ${this.bar} yo!`);
}
var f = new Foo();
f.baz();
Aside: Been working with InDesign's ExtendScript the past few weeks, it's been extremely painful. Won't even shim to ES5 completely/properly, cheating just to get most of ES5, and ES6 modules with Webpack.
[0] https://github.com/tc39/proposal-class-fields
The only thing I'm slightly disappointed in is that they didn't take the extra half a step to run the JSX version with React@16 proper. It would have been an interesting contrast, and maybe surprising. I would suspect that SSR + React's hydrate client-side might be the fastest to interactive of all of them.
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.Decent primer on ES6 class syntax. 1. Should use `TypeError` for the error message for an abstract class. 2. Missing class field declarations[0] (stage-3, but eminent). class Foo { bar = 'instance'; baz = () => console.log(`I'm context bound to ${this.bar} yo!`); } var f = new Foo(); f.baz(); Aside: Been working with InDesign's ExtendScript the past few weeks, it's been extremely painful. Won't even shim to ES5 completely/properly, cheating just to get most of ES5, and ES6 modules with Webpack. [0] https://github.com/tc39/proposal-class-fields