What is the difference between registerEarly !== true and registerEarly != true?
Hey there! welcome to the forums.
I believe the !== is the same as === which is checking for strict equality based on the type of value/variable you are checking. It is the more practical use case because often times in a production environment of code you donât want to have interchangeable types, especially when you have calculations that require numbers, if you pass in a string this could break the calculation.
the != is using internal methods to check if the values have a comparatively equal match. For example, if x = true which is a Boolean and you used the != like so : x != 'true' it would return false, even though you are checking a Boolean against a String.
1 Like
If we want to dial this in, the correct term is âidentityâ. In strict type matching there is no coercion so terms must be identical to each other.
== is âequalityâ, or as you describe, âa comparatively equal match.â This is loose type matching that employs coercion. Does coercing A to the same type as B result in a match? The real problem here is the reading required to fully learn and understand how JS performs coercion. This is a big question that would need to be answered if we are to incorporate loose type matching in our production code, with any certainty of itâs being failproof.
'42' == 42
vs.
42 == '42'
In which direction is the coercion being applied? Can we say with certainty that the coercion is always String to Number (as I suspect)?
true == 1
vs.
1 == true
is there even any coercion going on? Well, yeah, loose typing allows true to be a Number. We can prove this:
Number(true) // 1
Number(false) // 0
That is definite coercion being as it is deliberate. What we cannot do is trick JS into parsing an integer from a Boolean.
parseInt(true, 2) // NaN
We can go with some assumptions, based upon evidence: Boolean does not coerce to a String, would be one. Object does not coerce to Array, would be another.
Finally, what coerces to what? Itâs a tough question and one for intermediate learners to understand but not one that new learners need to know about, which would explain why strict type matching is broadly encouraged and enforced in lessons. We learners want to learn the tangible stuff before the grey area stuff. We just have to take it on faith that JS has some magic sauce in the background since there is so much evidence for coercion in the language. For another day.
2 Likes
Aside
TypeScript is an overprint (my term) of JavaScript that compiles to âuse strictâ compliance but gives oversight of the code through required elements in order to be syntax error free. Does that make sense? I donât know.
Itâs main goal is to have us write picture perfect code with strict type matching, homogeneous arrays, and the like. Quality production code. What is generated from that is strict JS that can reliably be served to any device and any local version of JavaScript (ECMAScript).
Long story short, it is a lot of work to learn TypeScript, and depends upon a solid foundation in JavaScript owing to the discipline and intuition required. Beyond that, itâs just another level of vigilance, on the whole. If one is planning to work in the industry, then set aside the few weeks it will take to get TS under your belt. It will teach one how to write stricter JS if we learn from the output it generates. Then just write code that meets that level of uniformity without TS. Key is to learn it.
2 Likes
Good to see you mtf! Itâs been a long time. You helped me a lot in my earlier days.
3 Likes
Great to see youâre still going at it! It is only by creating examples that Iâve been able all these years to keep an open mind, and stay close to the beginner level with enthusiasm.
3 Likes
Long live the beginners!
1 Like