Coercion, and the two kinds of equals

COERCION is JavaScript quietly converting a value from one type to another because an operator needed it to be something else. It is the source of nearly every joke made at this language's expense, and — used deliberately — also of some of its convenience.

The important word is quietly. Nothing warns you. An operator that wanted a number and was given text simply converts the text and carries on, and if the conversion produced nonsense you find out several steps later, usually as NaN or as a number with too many digits in it.

The cure is not to memorise the conversion tables. It is a habit: convert on purpose, at the edge of your program, and compare strictly everywhere. Do that and the tables stop mattering.

Every other arithmetic operator has one job. Not +. If either side is a piece of text, + joins them into a longer piece of text; only when both sides are numbers does it add. That single ambiguity causes more beginner confusion than anything else in the language.

So "5" + 2 gives the text 52, while "5" - 2 gives the number 3 — because subtraction has no text meaning at all, so it converts the text to a number and does the arithmetic. The same goes for *, / and %. Only + is ambiguous, and only + is the one you will reach for by accident.

It gets one step worse, because + is worked out left to right. 1 + 2 + "3" gives 33: the numbers are added first, giving 3, and only then does the text turn the result into text. Reverse it and "1" + 2 + 3 gives 123, because once the running result is text everything after it is joined rather than added. Nothing here is random, but nothing here is guessable either.

Number(value) converts to a number, String(value) converts to text, and both say plainly in the code what is happening. Number("42") gives 42. Number("twelve") gives NaN, which is the honest answer and is why you should check it with Number.isNaN before trusting the result.

Two conversions catch people out. Number("") is 0 — empty text becomes zero, not NaN — so an empty form field can silently become a real quantity. And parseInt("12px", 10) gives 12, because parseInt reads as far as it can and stops, whereas Number("12px") gives NaN because it insists the whole thing be a number. Neither is better; they answer different questions. Use Number when the whole value must be a number, parseInt when you are deliberately pulling a number off the front of something messy. Always pass 10 as the second argument to parseInt, so it can never guess a different base.

=== asks: same type, same value? If the types differ the answer is false and no conversion happens. == asks a looser question: could these be made equal if I converted one of them? So "1" == 1 is true, and 0 == "" is true, and null == undefined is true.

The trouble is that the conversions are not consistent with each other and cannot be reasoned out from first principles. null == undefined is true, but null == 0 is false even though many other conversions treat null as zero. Two values can each be loosely equal to a third and not to one another. There is a full table in the specification, and its existence is the argument against ever relying on it.

Hence the rule that essentially every JavaScript style guide states: use === and !== always. Not usually. Always — with one exception, below.

value == null is true for exactly two values: null and undefined. Nothing else. Not 0, not empty text, not false.

That makes it a precise, idiomatic way to ask the question you learned to ask in the last lesson: is there nothing here, of either kind? The strict version needs both halves — value === null || value === undefined — and says the same thing at twice the length.

It is worth knowing rather than worth insisting on: many teams ban == outright and write the long version, which is also fine. What matters is that if you do see == in good code, this is almost certainly what it is doing, and that you never write == for anything else.

Everything a program receives from outside arrives as text. A form field, a value read from a file, a number in a web address — all text, even when every character in it is a digit.

So the classic bug is arithmetic that silently becomes joining. A quantity of "2" plus 1 more gives "21" rather than 3, and nothing anywhere reports an error; a total is simply wrong on a screen somewhere. Worse, it may work by accident for a while, because every other operator converts properly — the multiplication in the same file is fine, so the value looks like a number until the day somebody adds to it.

The fix is a discipline, not a trick: convert at the boundary. The moment a value enters your program, turn it into the type it is supposed to be, check the conversion succeeded, and let everything inside work with real numbers. Module 7 builds that into a habit called validating at the boundary.

Coercion is automatic type conversion. + joins when either side is text and adds only when both are numbers; every other arithmetic operator converts to a number. Convert deliberately with Number and String, and check for NaN. Use === everywhere; the single defensible == is value == null, which catches null and undefined and nothing else.