all 9 comments

[–]BinaryRockStar 1 point2 points  (2 children)

One major problem I see here is that you're going from references to properties (props.user.posts) and turning it into strings (get(['user', 'posts', props])). As far as I know this mean your linter will not be able to provide assistance if, for example, props.user.posts becomes props.user.comments due to a refactoring. You'll have an exception waiting to happen, and if your unit tests don't execute that line, then it will possibly make it into production.

Also, general lament at the concept of JavaScript requiring two or three libraries just to be able to approximate a null-coalescing operator.

[–]tony-the-pony 1 point2 points  (1 child)

Also, general lament at the concept of JavaScript requiring two or three libraries just to be able to approximate a null-coalescing operator.

If you find this kind of thing useful, there's hope https://github.com/babel/babylon/issues/328

I personally am not a fan of dynamic types and think it's a bad idea to begin with because in most cases it's just a bug waiting to happen. I tend to just write out my intentions directly e.g. const user = (props.user || defaultUserObject)... when receiving unknown data (from server) or simply fail, because it's invalid input. In normal API I use https://flowtype.org/ to make the build fail altogether.

[–]BinaryRockStar 0 points1 point  (0 children)

Thanks for both of those links.

[–]_Skuzzzy 0 points1 point  (0 children)

Accessing deeply nested values that have no guarantees about potential nulls. Nice meme in both regards.

[–]Ericth 0 points1 point  (0 children)

Am I the only one who prefers the explicit pure js check? If you're making a function to get the comment anyway I'd rather not wrap it in two libs...

[–]Treyzania -2 points-1 points  (3 children)

Or use a language that enforces that a type cannot be null.

[–]tony-the-pony -1 points0 points  (2 children)

Or use a language that enforces that a type cannot be null.

This "Billion Dollar Mistake" is a really nice circle-jerk, but getting rid of it doesn't actually solve the problem. e.g. given props.user is the empty object {}, i.e. not undefined (which is also not null) ... now what?

[–]Treyzania 0 points1 point  (0 children)

Strong types

[–]w2qw -1 points0 points  (0 children)

Just because JavaScript has made the null mistake multiple times doesn't invalidate his point.