What if `weAreConnected` is `null` or `undefined`?

WalterSear's solution solves the issue since both `null` and `undefined` would become `false`:

    this.setState({
        isConnected: Boolean(weAreConnected)
    })

but in your case you could set `isConnected` to `null` or `undefined`

so if later in code someone makes the mistake of writing:

    if (this.state.isConnected === false) { /* do stuff */ }

they could have a bad surprise.

this.setState({ isConnected: !!weAreConnected })

This^, plus, you shouldn't really have "null" or "undefined" variables which you treat as bool (if you do, then that's a bug)

Ding ding ding right answer. This is the way most senior javascript devs would right it.

They'd right it if they were fixing it or write it if they were writing it ;)

It certainly doesn't hurt to "cast" the input to boolean. But your second example is the next code smell, because it should just be

  if (!this.state.isConnected) { /* do stuff */ }

(which still works as expected even when dealing with null or undefined).

Agreed, but you can't anticipate what another dev could write :)

Or if you pass down that `isConnected` down to a library where for some reason they assumed `null` should default to `true`

Of course it's very unlikely, but my point is you can't know all use cases of `this.state.isConnected` in advance on a large project so as you say it doesn't hurt to sanitize the input.

That's why there's PropTypes so you can define what type a given prop should be. An error is raised if a higher level component passes in a prop of an incorrect type.

this.setState({ isConnected: (weAreConnected === true) })

seems 100% equivalent

Another flavor of this surprise: JSON.stringify doesn't "see" undefined. JSON.stringify({foo:undefined}) returns "{}" :)

Because type (prototype) and data (Json) are two different things, if you need it -- JSON.stringify(obj, (k, v) => v === undefined ? null : v);

Or

  this.setState({
    isConnected: Boolean(weAreConnected)
  })

If you want to be super obvious, and aren't using a type system.

or

    this.setState({ isConnected: !!weAreConnected })

I prefer boolean, easier to see what's going on. And,

   bo-tab(

is only two more characters :)

It's not any easier if you understand what !! does. Pretty common usage across many languages.

>It's not any easier if you understand what !! does

which only applies if you're writing code for yourself. you can't expect everyone to know that idiom. same with using the + operator to cast to number, or an extreme case, the tadpole operator https://blogs.msdn.microsoft.com/oldnewthing/20150525-00/?p=...

!! is an extremely common idiom, across multiple different programming languages.

Code should be written so that it is understandable by other professional programmers, not people who started programming two weeks ago.

As a professional programmer, I've come to prefer code written to be understood by someone who started two weeks ago.

In that case, don't write any code. Don't use function. Don't use React. Don't use lodash. Don't use third party library.

People who only start coding for two weeks can't understand any code.

People who start has enough experience to work, but only start in this project for two weeks, will understand "!!" idiom.

Then by that principle you'd want to use !! since casting via function or constructor differs more between languages.

What it looks like in other languages is only minorly relevant to its obviousness and readability.

I don't see the argument that Boolean(val) "reads easier" than !! as long as you know what !! does.

Wouldn't any programmer recognize that Boolean(val) is a cast to a True/False value that's most likely an object, given the uppercase?

Perhaps, but it's a primitive, not an object.

I'm curious, which languages? I've never seen any of my colleagues write !!, ever, in C/C++, Java, Python, or Swift. I've also not seen it C# or Go, but my exposure is limited.

I've been paid to write code in Perl, PHP, Ruby, JS, Go, ObjC, and Java, plus a little C and Python, for going on 15 years. I'm pretty sure I've never written "!!" and I think I could count the times I've seen it used on one hand (maybe never in any codebase I've worked on, but I'm not entirely sure)

I feel sorry that they paid you then

C example from the Linux kernel: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history...

It's one of the earliest things I can remember learning in my intro to programming classes in college. Those were in Java.

I spend chunks of every day looking at a C/C++ codebase and have never seen this. Taught Java for a year in college, I have never seen this. I would leave a note to a student for using this to be honest - too unclear, and (as this thread denotes) not well known enough to put in production worthy code.

I'm pretty surprised to hear this from someone who taught a programming course. It actually makes a ton of sense when you evaluate what is happening: it's the negative unary value and then the negative unary result of that value - there's no possible way it could be anything other than true or false. It's more of a side affect of the unary operator ! than it is a language feature, which I believe is why it sees such ubiquitous implementation.

> I would leave a note to a student for using this to be honest - too unclear, and (as this thread denotes) not well known enough to put in production worthy code.

You've done a total disservice to your students that understood negative unary operations then. Given how many upvotes my initial post on this thread has (currently 38) I don't think the thread denotes what you think it does at all.

You're kidding, right? "!!foo" is a complete no-op in Java. It is never needed and never correct.

You're basically wrong on every single point. It's a syntactic hack in JS to get a guaranteed boolean coersion, but for anything else it's an absolutely pointless abomination. (Maybe PHP has a similar thing, but I haven't programmed in PHP, so I wouldn't know.)

In Java? What purpose would it serve there?

What? I've been coding in multiple languages for multiple platforms for almost 30 years and have never come across it. It seems rather unlikely that it's 'extremely common'

It is very common in C code, where for most of its history you hadn't any explicit boolean data type but used int, following the rule that zero is false and anything else is true.

The '!!expr' is the idiom most people use whenever the need for a canonical 0/1 representation arises.

Oh I understand, it, and used it for years. Boolean() is just easier to spot in unfamiliar code.

That goes to show how much salt you should take with the rest of his opinions on JS. Yes, dependency hell is a problem, yes, no type safety (though you can choose TS), the rest? Not so much unless you're trying to hammer JS into the shape of your old favourite language.

There's also the

    if isConnected {
      backgroundColor = .green
    } else {
      backgroundColor = .red
    }

bit, which should be a ternary.

I figure that a good rule is: if the feature existed in C, you should know and understand it. If that feature is convenient and doesn't sacrifice performance, then you should use it.

Then there's this blatant misuse of the arc4random API, which I'm pretty sure the manpage tells you about.

    let weAreConnected: Bool = arc4random()%10 > 4

it depends on how you want to structure your code and give sections to code.

"if (isConnected) {} else {}" emphasizes to me that there are two branches of code which depends on `isConnected` state. It may have only one thing to do right now. But this is major branch. Future git diff will probably show that the code in the body the branch are added/removed.

Ternary expression emphasizes on modification of a single attribute.

The replies below show why, because JS.

Bad languages don't allow a nice life.

It's funny how you can spot the junior devs, who are accustomed to one thing and refuse to learn another. There is a beauty about the JavaScript language that most people don't get, and how a lot of behavior can be added after the fact or mutated. Design time type safety is not the end all be all of languages

But inconsistency is truly a problem. Is not that JS is just "crazy" but with a method on his madness. Is that is just not well designed.

So, how we can claim to "developer good software" in front of our customers and defend tools like this?

I couldn't agree more. I wouldn't accept that from even a junior developer and yet you can easily find "senior" devs writing this crap. It seems like some devs will never understand that less code is better or that ease of reading matters. This is either lack of skill or laziness, neither of which are acceptable.