How is the `&&` operator working?


How is the && operator working?


When we use the && operator, also called the logical AND operator, if the left operand evaluates to true the right operand is returned, else the left operand is returned.

For example:

console.log(!true && 'hello world'); // here, the left operand evaluates to `false`, so `false` is logged to the console

console.log(true && 'hello world'); // here the left operand evaluates to `true`, so 'hello world' is logged to the console
1 Like

I don’t think the console would have any logs for the first statement.

Yeah But if you put her code into the inspect’s console then It will work just fine

A ‘log’ is a captured event being noted. There is a line being sent to record the event, whether to a line-printer, a file or the display. Our computer is full of databases that are basically nothing more than logs.

Every website has a timely log of every request it has received, and from where, and every response to that request. Even your household Wi-Fi connection has a log of every connection it has ever made.

We understand, ‘logging’, to this point. The disappointing truth is that JS doesn’t log (record) anything. If we want that done, we have to do it ourselves. When we see,


the only logging that gets done is directly to the screen and it passes out of existence, except there where we can see it. Nothing is stored of this transaction.

Now if we look at JS functions in general, they always have a return value. If none is provided by the function, JS supplies the default, undefined.

 > console.log()
<- undefined

Consider the above in the context of the following:

 > console.log("Hello, World!")
   Hello, World!
<- undefined

It’s a terminal event that is last ‘logged’, euphemistically speaking, at this point, namely the return value of the last function to execute prior to termination. In the case of, console.log(), it will always be, undefined.

Hopefully we’ve cleared the air with respect to console.log(). It has, literally no bearing on the program and should never be confused as useful, beyond our pressing need to see something on the screen, which is also a fools errand when we consider that logging is held up in a call stack when our function has repeated logs in a loop.

What does that mean? Have your script count to a 1000 and log it as it counts. It should come as no surprise that it is a fool’s errand to log inside a loop. All the logging will occur when the loop is complete. This should come as a lesson. Store values in an array, and log that, or create a generator that completes its task on each generation. The latter is for down the road, quite a ways one might add.

Given that return has come up, repeatedly, one hopes we are straight on how this has nothing in common with logging and is not interchangeable. Every function has a return value. There is good reason for that… It’s what functions are supposed to do; give something back. We feed a value into it, and get a result back after some processing in between.

const foo = function (x) {
    return `You supplied, "${x}", as the argument in a call to foo().`
 > foo ("Hello, World!")
<- You supplied, "Hello, World!", as the argument in a call to foo().

When we look at the above we see that the terminal event is a return, so that is the value that is displayed, even without using console.log(). Notice there is no, undefined? The console is logging its terminal event at all times, and it is always a return value of one sort or another.

Take all this in stride with what you are learning of the console, that is if and when you take a serious look at its uses. As always, happy coding!

Ahh, got it.
I do see false being logged, actually, so disregard!