Doubt between == and === in a lesson

[naive gale]

Hi, in this lesson https://scrimba.com/learn/learnreact/forms-in-react-checkbox-co6da4637a27cca33be7cb1d7 on line 19 (please drag the slider to the end) , why does he use === instead of ==? type is of type string right? And if we compare same types of data, we can use == right?

[south shale]

Just how we do it, always use ===.

Was an addition to Js after problems with ==.

[naive gale]

what kind of problems?

[south shale]

"1" == 1 would be true

That doesn't make sense

It did type coercion which wasn't wanted

Also true == 1 was also true

It was just unwanted behavior

This is ==

This is ===

[naive gale]

i understand
but in the specific example, type which is equal to event.target.type is already of type string right? so there wont be event coercion

[azure gorge]

Using == is perfectly fine.

[south shale]

No... You're asking for problems in the future.

Just always use ===

If you get the funky type coercions then sure use ==, if you don't then don't use it.

[azure gorge]

For example:

"I don’t think we need to “fix” types in JS (like TypeScript or Flow), I think we just need to understand them better and more clearly communicate our types in JS. For example, completely contrary to most common belief, the == operator is actually more powerful and more useful in our programs than ===, and in fact, usage of == should be preferred and === should only be a last option. But to understand why I make that claim, you have to actually learn types, and the way they’re converted: coercion. I really wish developers wouldn’t just keep parroting back “JS types are evil” like they’ve heard for years. They’re great, and your programs suffer if you don’t learn and use them to their full potential." (from https://levelup.gitconnected.com/kyle-simpson-ive-forgotten-more-javascript-than-most-people-ever-learn-3bddc6c13e93)

or if you read https://notlaura.com/notes-kyle-simpson-javascript-spirit-guide/ .

[south shale]

the tldr on that is legit what i said:
If you get the funky type coercions then sure use ==, if you don't then don't use it.

[naive gale]

ok i see what you mean

[south shale]

also typescript ftw

[azure gorge]

I don't agree. There is nothing funky about coercion. You use it all the time, and its one of the JS benefits. The key is to know your types and also coercion.

[south shale]

[1] == true is not funky?

false == [[]] is not funky?

[naive gale]

as someone with a c++ background, it definitely caught me offgaurd

however if someone wasnt used to dealing with strict types, he might not find it weird

[naive gale]

also cool graph

[south shale]

someone on so made it

[azure gorge]

No, when does it happens? In your example written here... as I said, you have to know the tool you are using (JS) and case scenarios you are developing your JS algorithm for.

Coercion has its quirks, but then again, you have to know the language you are using.

[south shale]

You can't tell me JS is perfect, because that's what you're insinuating. "It will never f___ up". You as a developer have to prepare for every scenario.

Rather, just not touch the funky and prepare for the worst in your code.

[naive gale]

i think it's a matter of perspective

[south shale]

But it all goes back to, if you know what's happening and what you're doing then don't care what I say, if you're a JS beginner rather just not run into this unexpected behavior.

[naive gale]

👍 i'll go back to my lesson
thanks for the advices 😃

[azure gorge]

I didn't say that, in fact, I don't know anything that is perfect. You do you. I am just saying that == has its place in JS. Another point is, that == checks as the first thing if both operands are of the same type, if yes, then it does exactly the same as strict equals.

Bottom line: we as developers have to know the types we work with in the first place, and not be surprised by them.

[south shale]

So your bottom line is ignore JS sucks and is totally random from time to time and we just have to see that coming instead of doing better.

[azure gorge]

Not my words. btw how is JS random from time to time? Anyhow, so you always use === and never ==?

[silent prism]

== produce ambiguity sometimes, for fine results always use === for correct typeset. But i think sometimes it is best to have string number comparisons. You not need to parse data to same data type.

[mild thunder]

good luck trying to understand the whole behaviour haha 😄

There are certainly scenarios where double equality can be useful, but I would not recommend overusing it.
eg.: ```js
if (value != null) { // etc... }
if (value == null) { // etc... }

The scenario above already depleted all of my preferred use cases for double equals.

I always use strict equals when it comes to comparing primitives.

@azure gorge JS has good and bad parts. Sadly it mainly has "bad" parts and the language is getter over-bloated with loads of crap from other languages. Most of those feature are not needed at all and has very rare use cases.

You quoted somebody who stated we shouldn't try to fix types in JS.
JS had been written in 2 weeks, it has a very poor design.
Having to work and THINK in types are 2 very powerful tools you can get, it will make your life so much easier.

Since JS coerce almost everything most of the time into something "unusual" it makes the language looks unpredictable when actually it is not, when you understand what is going on under the hood.
BUT the problem is understanding this weird behaviour which is not a pleasant road and I would recommend everybody to ready through the docs once, then forget about it and just use strict equals everywhere.

[azure gorge]

Yes, checking for null with equality https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Equality can be a good use case, as undefined coerces into null and via versa.

[azure gorge]

On this whole topic, ie also about equality, I'd like to say I welcome anyone to go through the https://frontendmasters.com/courses/deep-javascript-v3/ course and I'd be interested what anyone would want to say afterwards.

[mild thunder]

Awesome material. I'll definitely look into it, but I do not believe it would change the way I do equality check.

[azure gorge]

Sure, I just share it in the sense of more information, and also as a resource that I've used to learn about JS. Needless to say, I am still learning, also here and thanks to our discussions.

[mild thunder]

I love how much you contribute to this community. You always have some unique questions which are very valuable to me and I am sure to others as well! ❤️
I am learning a lot from you and I love that both of us has different perspective on certain things and this makes this forum very vivid (in the best way possible) and I love hearing from your experiences and views, so thank you for being awesome! 💪