You're mistaken. The array is coerced with the internal statement of ToPrimitive(type on the other side), which in this case is the boolean that was previously coerced to number, see tc39.es/ecma262/#sec-islooselyequal - so it depends on what the array is compared with.
Granted, the post seems to wrongly imply that the coercion to number is always the case.
Post is implies that it coerced to number. Thats correct its loselyequal implies thats for == and not for ===. so complete post is written with context of ==. Refer freecodecamp.org/news/js-type-coer...
I think the implication wasn't consciously made here. I am obviously aware this is about isLooselyEqual (==), because strict equality would not do any coercion whatsoever.
And here I put a link to the actual ecma standard that officially defines how JS is supposed to work in my answer that explains what is happening and you think you can refute that with freecodecamp?
I invite you to read the actual standard. It's a bit dry, complicated and sometimes slightly confusing, but it'll really help your understanding of the language.
This blog is all about how isLooselyEqual (==).For much more in deep, context of blog will change. If this would not be about isLooselyEqual (==), then you might have find the === too. I completely agree with you and your context. And its really good part that, now our reader can get more depth knowledge that how == and === make the things different. But its completely different topic.
Sorry folks, I didn't mean to start a heated debate! I was mistaken, original article was indeed correct, even if it could have gone into a little more detail. I've edited my original post with a note.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
You're mistaken. The array is coerced with the internal statement of
ToPrimitive(type on the other side), which in this case is the boolean that was previously coerced to number, see tc39.es/ecma262/#sec-islooselyequal - so it depends on what the array is compared with.Granted, the post seems to wrongly imply that the coercion to number is always the case.
Post is implies that it coerced to number. Thats correct its loselyequal implies thats for
==and not for===. so complete post is written with context of==. Refer freecodecamp.org/news/js-type-coer...I think the implication wasn't consciously made here. I am obviously aware this is about
isLooselyEqual (==), because strict equality would not do any coercion whatsoever.And here I put a link to the actual ecma standard that officially defines how JS is supposed to work in my answer that explains what is happening and you think you can refute that with freecodecamp?
I invite you to read the actual standard. It's a bit dry, complicated and sometimes slightly confusing, but it'll really help your understanding of the language.
This blog is all about how
isLooselyEqual (==).For much more in deep, context of blog will change. If this would not be aboutisLooselyEqual (==), then you might have find the===too. I completely agree with you and your context. And its really good part that, now our reader can get more depth knowledge that how==and===make the things different. But its completely different topic.The main point here raised by lionel-rowe is the question why the array was coerced to number instead of string and the post did not answer that.
Sorry folks, I didn't mean to start a heated debate! I was mistaken, original article was indeed correct, even if it could have gone into a little more detail. I've edited my original post with a note.