In today's world of JavaScript, there's a huge number of tools that solve the same problem in slightly differing ways. Some of the tools are driven...
For further actions, you may consider blocking this person and/or reporting abuse
Please don't recommend Boolean as boolean type check.
With your approach, you'd incorrectly conclude that a variable of
false
passed to Boolean() is not a boolean.Boolean will cast to boolean.
Since non-zero numbers are truthy, they will give you a response of true even though not boolean type.
You should use
Bonus points if use you TypeScript
Explicitly checking truthiness is better than implicitly checking, and to do that you need to use strict equality true/false, as all other checks are implicit by means of coercing a value to a bool.
Assuming your comment was on my previous comment and not the TypeScript one, as TypeScript will check type is a boolean for you using
myVar: Boolean
.Use this to check for type boolean:
Use this to check if a value is actually
true
and boolean, not just truthy. Because triple equals sign does a type checkBeware the double equals sign which coerces ie is checks for truthiness and also handles strings funny.
I don't see a common reason to use
Boolean()
.It adds change in logic here so is verbose.
If you want to be explicit in logic flows use triple equals and a value.
You could use
Boolean()
to convert to a Boolean type but I can't remember needing to do this in JS.Boolean docs
Relying on TS to ensure type checking is fraught with danger esp with input data. TS isn't a runtime environment, it's just a transpiler.
Boolean(a)
is equivalent to!!a
Explicit checking requires strict equals, in my previous comment, but you will need to test for
true
andfalse
.Okay thanks. I didn't understand your TS before.
Yes if you have user input you could pass non accepted type to a function. That is a risk for all types and not just boolean and there are a few ways to do that.
Like
myVar as Boolean
.Or if your input can't be trusted, then add some sanitization on your form handling or use a check before or within the function as
typeof myvar === 'boolean
.Like I said earlier,
!!prop
andBoolean(prop)
are fundamentally the same - they determine the truthiness of a value by coercion, not if it is in fact a boolean, just that it has a value other than""
,null
,undefined
,false
and0
. Given an array and object share the same super typeobject
, truthiness check will always returntrue
.typeof myvar === boolean
isn't required when you can just doprop === true || prop === false
and explicitly check the values, rather than the type.Lodash explicitly checks the truthiness of the var, and some other checking for arrays and objects. My suggestion isn't a hard and fast rule, it's just one of many options and it's a useful shorthand check. Feel free to use
!!var
,Boolean(var)
or copy+paste the lodash code.Ok thanks. My original point was not on the best way to do truthiness though but the fact that these two are not interchangeable as you had suggested, so was recommending it be fixed.
I agree. Lodash is totally unnecessary when bundle size matters. Invest more time in learning how specific functions work to save time and resources down the road. Nonetheless, Lodash and jQuery will always have a special place in my heart.
Yep, +1
Try indent your code so your bullet points number correctly
Below
You can indent 4 spaces in addition to code fence block.
Result
A
B
I agree with a bit of this. Sometimes it's simple enough to use
forEach
ormap
orreduce
directly. And honestly, I wasn't familiar with the spread syntax, and that is 🔥But there is a bit of a strawman argument here. I don't care about cross-browser compatibility (or browser download size so much at the moment given that I'm doing a lot of Node.js). You've skipped past many of the conveniences of
lodash
which make it quite worthwhile:partition
alternative, but, please, that is so ugly. Why should we spend our time writing that and struggle getting it right?map
oreach
orfilter
, there is so much convenience is being able to use the simpler forms like_.map(arr, 'foo.bar.bar')
or.filter(arr, {key: value})
.Just in general, it's nice to have around to do the simple things (like
partition
, but much more of course) that I shouldn't be spending my time worrying about. And it provides a consistent interface to it all. Your examples about type inference and checking just make me ❤️ lodash even more because, just look at those JS examples. It's a such mismash! 😃Thanks for the post!
Lodash and Underscore are two of my common pet peeves. In fact, I was just talking to our team about this last week, because we are porting over old code and I specifically said that I didn't wanna be dragging over all the old Lodash stuff, just because it's an easy copy-n-paste.
Those packages were awesome - 10 years ago. Now, they're mostly superfluous. And they serve as crutches for those who haven't bothered to learn modern syntax.
Yep, 100% agree
Do you think maybe we'll always need something like Babel? So it won't go away.
There are always going to be legacy browsers and users who have to update. When they've all caught up to using ES6 in a few years, by then there is some newer syntax they don't have support for. So you going to need to transpile down to ES6 or ES7, rather than to pre-ES6.
Babel will be required for users on older browsers that don't support bleeding edge. Es6 and even es7 sugar is no longer transpired unless specifically configured. Null coalesce and optional chaining do get transpiled.