DEV Community

Cover image for It's time to let go of lodash

It's time to let go of lodash

Justin Mitchell on February 16, 2021

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...
Read full post
Collapse
 
michaelcurrin profile image
Michael Currin • • Edited

Please don't recommend Boolean as boolean type check.

Boolean(true);
// true
Boolean(false);
// false
Enter fullscreen mode Exit fullscreen mode

With your approach, you'd incorrectly conclude that a variable of false passed to Boolean() is not a boolean.

Boolean will cast to boolean.

Boolean(1)
// true
Enter fullscreen mode Exit fullscreen mode

Since non-zero numbers are truthy, they will give you a response of true even though not boolean type.

You should use

typeof 1 === 'boolean'
// false

typeof true === 'boolean'
// true
typeof false === 'boolean'
// true
Enter fullscreen mode Exit fullscreen mode
Collapse
 
michaelcurrin profile image
Michael Currin •

Bonus points if use you TypeScript

function hello(greet: Boolean) {}
Enter fullscreen mode Exit fullscreen mode
Collapse
 
jmitchell38488 profile image
Justin Mitchell •

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.

Thread Thread
 
michaelcurrin profile image
Michael Currin • • Edited

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:

typeof myValue === 'boolean'
Enter fullscreen mode Exit fullscreen mode

Use this to check if a value is actually true and boolean, not just truthy. Because triple equals sign does a type check

myVar === true
Enter fullscreen mode Exit fullscreen mode 
1 === true
// false
Enter fullscreen mode Exit fullscreen mode

Beware the double equals sign which coerces ie is checks for truthiness and also handles strings funny.

5 == "5" // true

0 == false // true
Enter fullscreen mode Exit fullscreen mode

I don't see a common reason to use Boolean().

It adds change in logic here so is verbose.

// this checks for truthiness twice 
if (Boolean(myVar)) {}

// and equivalent to just this which checks once.
if (myVar) {}
Enter fullscreen mode Exit fullscreen mode

If you want to be explicit in logic flows use triple equals and a value.

// true for 1. and false for 0 and 1000 and any non Number type
if (myVar === 1) {}

// true for true only and false for everything else.
if (myVar === true) {}
Enter fullscreen mode Exit fullscreen mode

You could use Boolean() to convert to a Boolean type but I can't remember needing to do this in JS.

var myNumber = 1 // or 1000 or 0 or -999 etc.
var myBool = Boolean(myNumber) // can be true. Or false for myNumber equal to zero

var a = Boolean("my string")
// true
var b = Boolean("")
// false
b === false
// true
Enter fullscreen mode Exit fullscreen mode

Boolean docs

Thread Thread
 
jmitchell38488 profile image
Justin Mitchell • • Edited

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 and false.

Thread Thread
 
michaelcurrin profile image
Michael Currin •

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.

Thread Thread
 
jmitchell38488 profile image
Justin Mitchell • • Edited

Like I said earlier, !!prop and Boolean(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 and 0. Given an array and object share the same super type object, truthiness check will always return true.

typeof myvar === boolean isn't required when you can just do prop === 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.

Thread Thread
 
michaelcurrin profile image
Michael Currin •

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.

_.isBoolean(true); //true
Boolean(true); //true - same as above line
Enter fullscreen mode Exit fullscreen mode 
_.isBoolean(false); //true
Boolean(false); //false. But different result to above line and therefore not equivalent
Enter fullscreen mode Exit fullscreen mode
Collapse
 
johannel00 profile image
johannel00 •

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.

Collapse
 
jmitchell38488 profile image
Justin Mitchell •

Yep, +1

Collapse
 
michaelcurrin profile image
Michael Currin • • Edited

Try indent your code so your bullet points number correctly

Below

1. A
Enter fullscreen mode Exit fullscreen mode

You can indent 4 spaces in addition to code fence block.

    ```js
    console.log()
    ```
Enter fullscreen mode Exit fullscreen mode

Result

  1. A

    console.log()

  2. B

Collapse
 
cheerfulstoic profile image
Brian Underwood •

I agree with a bit of this. Sometimes it's simple enough to use forEach or map or reduce 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:

  • The ability to chain multiple functions together nicely
  • You wrote a partition alternative, but, please, that is so ugly. Why should we spend our time writing that and struggle getting it right?
  • When using map or each or filter, there is so much convenience is being able to use the simpler forms like _.map(arr, 'foo.bar.bar') or .filter(arr, {key: value}).
  • It makes working with enumerating over objects simpler than plain JS

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!

Collapse
 
bytebodger profile image
Adam Nathaniel Davis •

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.

Collapse
 
jmitchell38488 profile image
Justin Mitchell •

Yep, 100% agree

Collapse
 
michaelcurrin profile image
Michael Currin •

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.

Collapse
 
jmitchell38488 profile image
Justin Mitchell •

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.