Watch This If You Don’t Understand Type Coercion

JavaScript Simplified Course: javascriptsimplified.com
Type coercion is a confusion topic for many JavaScript developers and most never truly understand how it works. Because of this many developers write bugging code using the bang operator without even realizing it. In this video I will be discussion the potential downfalls of the bang operator as well as how to avoid them.
📚 Materials/References:
JavaScript Simplified Course: javascriptsimplified.com
== vs === Video: • JavaScript == VS ===
== vs === Article: blog.webdevsimplified.com/202...
🌎 Find Me Here:
My Blog: blog.webdevsimplified.com
My Courses: courses.webdevsimplified.com
Patreon: / webdevsimplified
Twitter: / devsimplified
Discord: / discord
GitHub: github.com/WebDevSimplified
CodePen: codepen.io/WebDevSimplified
⏱️ Timestamps:
00:00 - Introduction
00:29 - Why this is bad
03:38 - Implicit vs explicit type coercion
05:00 - How to fix this issue
#TypeCoercion #WDS #JavaScript

[@MrREALball]

It is just a matter of understanding and remembering which values are considered falsey. I always write code like this (short hand that is) and had no problem with it.

[@mykalimba]

Yes, this. The programmer has to understand the context in which their code is written, and make sure the appropriate constructs are used. It's not that using "if (!something) {...}" is inherently bad; it's using it incorrectly that's bad.

[@mikeonthebox]

The example he used was terrible, because even without the ! the code would produce the same results. 0 would still be false.

[@CottidaeSEA]

@@mikeonthebox That's the biggest issue I have with his videos and advice in general. What he says isn't necessarily bad, but he sometimes tries to back it up with awful examples.

[@TrackedHiker]

Javascript’s falsy/truthy evaluation is one of its worst features. It’s terrible. Stop using it. Be explicit by comparing to undefined or null or empty string or whatever. You’ll thank me some day.

[@CottidaeSEA]

@@TrackedHiker Depends on what you're trying to do though. Checking if a string input is empty and then doing an early return is fine. Then you don't care if it's undefined, null or whatever else it may be. If a string is required for further usage, I'd say the following is sufficient: if (!input || typeof input !== 'string') return; The thing I find more evil is the following: if (input) { // Do stuff } The problem with that code is that you've really only asserted that there is a value, not what it is. That is inviting far more trouble than !input will ever do based off my own experiences.

[@rexkenley]

The problem is not type coercion, the problem is not understanding falsies. ![].length is a common pattern to check for empty arrays. Ps. Your code allows negative values, that's a bug.

[@debo4jc]

But he wasn't doing this video to write an actual check on number of children. It was to prove how to properly check if (in this instance) that value was an actual number, and a negative number is still a number. Right?

[@mikeonthebox]

@@debo4jc No, the example was to show why using ! is "bad" but even without using ! the code wouldn't work, as 0 is false still, so the outcome would be the same either way.

[@rexkenley]

@@debo4jc Then the example shouldn't say number of children. It should say enter a number. I don't think this is a good example about the pitfalls of type coercion. null is an assigned value, all variables start with undefined. The proper solution is if (numberOfChildren !== NaN && numberOfChildren > -1)

[@tomshieff]

It's not a bug, it's a feature: You can have a negative number of children, kind of like a contraceptive method.

[@angrytvrobot6130]

@@tomshieff If having children gives you less money, then having negative kids gives you extra money!

[@DzikiMoronHackshield]

I think what using this operator is very useful, espacially with objects. It covers undefined and null. Bang operator only makes problem with number type.

[@MrAntice]

It's all about knowing what you are actually checking for. If I check for a number or string, I use typeof instead. for anything else, bang does the job just fine.

[@DzikiMoronHackshield]

@@MrAntice Yes, you are right. That's why I wrote this comment - I think that author demonize this operator

[@DzikiMoronHackshield]

for example what's wrong with even if(array.length) ... else. Length is a number, but we can use bang - it is shorter and clearer

[@MrAntice]

​@@DzikiMoronHackshield There is absolutely nothing wrong with it, and it's easy to understand the question posed in the if. Is the bag(array) empty? This video uses a very common mistake in coding, but it's not the bang operators fault. The coder is simply asking the wrong question. I read somewhere, (cant remember where anymore), that the best way to handle branching logic is by posing it as proper questions first, then convert it to code afterwards. Have made a lot less mistakes after changing to that method.

[@CottidaeSEA]

@@DzikiMoronHackshield Array being undefined will throw error. At least make it array?.length. In which case !array?.length would be appropriate to check for empty or null array.

[@rand0mtv660]

Yeah this isn't necessarily bad, it just has its quirks. When it comes to numbers, I usually go for more explicit checks such as "x > 0" or "arr.length === 0" etc. in order to make it clearer what I'm checking for and to avoid these quirks. For example, when it comes to React, using "arr.length && " will result in number 0 being shown in UI when that arr has no elements, so being more explicit will avoid that bug.

[@stephenJpollei]

Yeah, I would of done if (numOfChildren >= 0) { /*sucess*/} else if (numOfChildren < 0) { /* negative children*/} else { /* NaN */ }

[@Romulusmap]

I can't say how much I appreciate the content you created over the years. I watched a lot of KZbin tutorials, but you're the only one that made me actually want to learn new things, because you explained every concept in the most clear and logical way. I might soon get a job in the field, and I don't think I would if I haven't stumbled onto your channel. I am eternally grateful for everything you do, you're the best, thank you, have a nice day!

[@djisscc1924]

The thumbnail is incomplete, using the bang operator is bad if you don't know its implicit implications. Otherwise it's pretty useful. And much more powerful with typescript.

[@algj]

I'd assume "user" is some ID or username, so the thumbnail can be misleading

[@Richard_GIS]

But the main problem with your code is that you fixed the ! stuff but what about negativ values -so a full done xample would have been really apreciated, now it looks a little bit incomplete

[@doubledomination7398]

That's why TypeScript become a de facto standart for a JS develeopment.

[@QwDragon]

The only values with which cast to boolean doesn't work fine are zero and enpty string. The most common case of using if (!smth.smth) is to check for object. Completely disagree with the point that implicit coercion should be avoided. It should be used almost always unless in this place it doesn't fit. But parseInt should be avoided almost always. It introduces the bug with parsing prefix instead of the whole input. But in you code normal cast to number will return 0 and not null, so that code is already broken. Instead for numeric inputs you should use input.valueAsNumber. And for string input check to space-only string before cast to number.

[@abhayshrestha7797]

U have helped me a lot many time thank you♥️

[@royzelig]

I have to disagree on this one, JS gives you power tools, use them right. 0 == false isn't a bug. write your code knowing what it does and you're perfectly fine with this "!value" syntax

[@TrackedHiker]

“Power tools” like a chainsaw that has no kickback bar and randomly turns on by itself? Yeah no thanks. Falsiness and truthiness aren’t features of JavaScript. They’re defects.

[@agentvettel8720]

bool is actually interesting type value is false it is 0, value is true when value isn't 0, so, nothing special about 0

[@TrackedHiker]

@@agentvettel8720 but `false === 0` is false, as is `true === 1`. Dig deeper.

[@vanlepthien6768]

Bad language feature. Why bad? Because otherwise videos like this one wouldn't exist.

[@eobardthaw]

@@vanlepthien6768 I agree

[@TECHN01200]

This is only a problem in weakly typed languages. In strongly typed languages, if statements require a boolean, if you are checking anything else, there must be an explicit comparison somewhere.

[@m7mdnho154]

laughs in TypeScript:

[@soniablanche5672]

in C, booleans don't even exist. 0 is false and any number is true.

[@michael22000]

Typescript ftw.

[@joshfortran2468]

I never saw a person using a bang operator on a integer value. I think this video is addressing a problem that in almost all cases doesn't even exist, in all modern compiled language you can't even use this operator on value types, it's just how js works which allow any kind of operation. I mean, the video give some interesting explanation for newer people but really not pratical, if the documentation says that the parse might return NaN just check for NaN?

[@BeCurieUs]

We (by we I mean I) had a case of this in our production code. Basically, we had old BE data that was being passed to us, and potentially new FE data that the user was inputing. They could save, so we would need to transform the data and send it to the backend, EITHER the old data or the new data. Of course, dumb me used code like this NewBeData = NewFEData || OldBeData. After watching the video you will understand why this is bad. If the user types in valid but falsey values, it will not update. So if a fee was 0 dollars, it would not save that...oops. And while the video suggests a great pattern, another is the null coalescing operator. You can think of it as a special case || operator. It looks at the first value, and if it is null or undefined, it uses the second value. Super handy in very specific Type Coercion situations.

[@simonwillover4175]

I always end up adding z bunch of explicit options rather than just using the bang operator. I only use the bang operator when im literally thinking "is it 0, bull, undefined, or an empty string" specifically, which is rare.

[@JZ-ey6pv]

Thanks for the details!This is why I never feel comfortable on js… so many edge cases I can go wrong… and not easy to test it out. I know I am going to forget this video next week. Why don’t we all go back the strong typed…

[@zxph]

Well jotting these tips down in a note could help for you to remember until it comes automatically with practice. As for strong typing, you could always just use TypeScript instead

[@uzairmughal7461]

Man! your content is quite easy to get and understand even for a beginner!

[@codingwithgyver1637]

Seems need to check my angular code because of this. thank you very much

[@paokalexthes]

I think it would also be useful to show that empty object or empty array are truthy. I think more people confuse those ones than they do 0

[@ackerman98]

Use Nullish coalescing operator, it will return true except Undefined or Null if I'm not mistaken

[@ades1739]

At 6:22, shouldn't you use the || operator ? With the && the if will always be false no ? Since the variable can't be null and NaN at the same time. Or am I missing something ?

[@learn029]

How to chance formik initialState values based on stateChanges inside useEffect? (multiple values at onces)

[@juliohintze595]

When I'm checking if a value is a number, I use Number.isFinite(value) (not the same as window.isFinite). It returns false if the type of the value is not a number, and also returns false if it is NaN.

[@Rudxain]

That's a nice way to ensure a value is a non-problematic valid numerical value. The only downside is that it doesn't support object-wrapped Numbers, because it sees them as Objects instead of Numbers, even though we can use valueOf() to get the internal primitive value

[@juliohintze595]

@@Rudxain Huh, I didn't know that. Good to know, thanks. Do you use these object-wrapped numbers often?

[@Rudxain]

@@juliohintze595 No, lol. They're not necessary in most cases. They could be seen as a consequence of how ECMAscript works, and the fact that "everything is an object" in JS. Some JS methods are "aware" of Object-Wrapped primitives, but Number static methods intentionally ignore them because they are not quite primitive numbers

[@viljamilofqvist2112]

As java programmer i have never needed to think about something like this

[@a-fletcher]

Something I would like to know is if this is as important in typescript? for example you know the input will be (string | undefined) or (boolean | undefined).

[@jacobstern2150]

String is problematic because the empty string is falsy. But sometimes you do want that behavior. Overall I think it’s common to use the bang operator liberally in typescript because it’s less likely to cause an unexpected type coercion.

[@a-fletcher]

​@@jacobstern2150 Ah I see how that can be a problem and could cause some issues. Definitly something to keep in mind when using. Thanks for the knowledge.

[@jacobstern2150]

@@a-fletcher Yeah as I said it’s still okay to use the bang operator for strings in my opinion but you have to be aware when reading and writing that it means (s != null && s.length > 0)

[@PeacefulMindss]

It's a js problem, any type other than bool shouldn't be allowed to use "!" The first place, unless in something like "! int1 == int2", anyway .. KZbin suggested the wrong thing again, please guys add "JS" to the title of your js videos if you can, keep up the good work man 👍.

[@GlaucoMorais]

The incredible of JavaScript is that NaN is a number.

[@timchen8512]

You make my day….lmao

[@fadfooood]

Would the nullish coalescing operator work here? Assuming the input type is a number

[@soniablanche5672]

no, NaN is not null

[@Corleone007]

Is that music intro yours :) ? as I saw guitar in your room corner :D

[@soul1543]

The thing with the != null is that I think that wouldnt always work with undefined or NaN values, so you'd have to write 3 or more checks in your if statement

[@bayrock1337]

This is why nullish coalescing exists (??). You could also try casting the value to a boolean (!!).

[@soul1543]

@@bayrock1337 hey, good answer how would I apply ?? for this usecase? Something like?: If(user ?? false) { }

[@soniablanche5672]

it works with undefined, that's why Kyle uses it.

[@williebanda3912]

Kyle must create a study guide for web development. I would buy the book. His tips are really good.

[@rishu_rvlogs5113]

cou,d you make a video on how to use a debugger in vs code for react developer?

[@kasmanialisaad]

Couldn’t you do if (!input.value.trim().length) ?

[@kathleensarkeesian8506]

That is the approach I used in one of my projects

[@mikeonthebox]

Do you need to trim()? Don't think you can use spaces in a type number input box. But also, what would happen if someone enter 4.345 for example.

[@kasmanialisaad]

@@mikeonthebox it’s more of a general way I use for all inputs not just numbers. So spaces can be used. 4.345 would still be a string when the value is taken from the input so it would still work.

[@MOUNIROU60]

the expression inside the if statement in 6:26 can never be true because they are mutually exclusive, there should be an OR not an AND there, i know you know, but i just wanted to point it out in case you missed it in the editing.

[@fuhoo5836]

as everyone else has said this is about understanding falsey. also your code allows negatives.

[@trappedcat3615]

5:15 use === when checking null and undefined if their strict equality matters null == undefined // true

[@michalnowak2181]

Thx

[@yadusolparterre]

Didn't you make a video about how you should replace "isNaN" by Number.isNaN?

[@CaptainCsaba]

It's perfectly fine to use this if you can remember the 6 falsey values that can happen and you determine that they will not screw up your function.

[@IlyaTkachenko13]

Implicit conversion is dangerous, it's nice point. But i have a question. Can 'parseInt' return null?

[@love-hammer]

From MDN: If not NaN, the return value will be the integer that is the first argument taken as a number in the specified radix.

[@hierotsu]

False is different from null, so I guess your solution is not "universal". So I feel this video, despite being useful for some and you having explained there's different cases, doesn't reach its potential of explaining checking falsy stuffs. Thanks anyway, you do a great job!

[@SteinGauslaaStrindhaug]

Assuming this is for inputting how many children you have (and not some weird setting where negative children makes sense, whatever that might be), the most correct and readable solution would be: if(numberOfChildren >= 0) { // success } else { //error } Here you let type coercion work for you and not against you. Since parseInt will return only NaN or a Number, and NaN is neither equal, greater than or smaller than anything, so this would only accept positive integer values of children.

[@SteinGauslaaStrindhaug]

Assuming this is an application that deals with something perverse where children can be owed so it makes sense to have negative numbers, so you want this to be success for any finite integer, use if(isFinite(numberOfChildren) { // success } else { //error }

[@harshrathod50]

This is completely safe in TypeScript. ❤️🔥

[@Learnbynet]

you need add type in jsdoc or ts

[@navjotsingh2457]

Tysm

[@bayrock1337]

I think it's been pointed out, but understanding false values in JS is the important takeaway.

[@love-hammer]

One of the things that drove me crazy with learning JS was how something like a number could be 3 different types (or a value that is literally _not_ a number but is of type number, but I digress). Rather than constantly checking for null/undefined or NaN you could just give numbers a default value and correct the result of functions like parseInt to be a default value, like 0. The point is the same though, implicit typing can create unneeded risk. It can also get in the way of self-documentation because it's not clear if not allowing 0 is a bug or a requirement.

[@dhampson545]

Reminded of early web stores. Enter 0.1 items and give yourself a 90% discount.

[@mgbertiaux]

This looks like: Hey! Don't buy shampoo if doesn't have printed instructutions in the package. Remember, read instructions each time to use it, for the rest of your life, is for your safety

[@dev.mohammedabdulaziz4376]

i don’t think my database will return zero as a user it will return either null or an object

[@tejasvakharia4118]

Why would some one use ! In case of numeric conditional check ? If bool conversion then dev will use !. In such such isnan will work

[@chudchadanstud]

So this is the power of JS. The absolute state.

[@hikari1690]

I never know when to use innertext and textcontent

[@xBZZZZyt]

00:37 use numberOfChildren>=0&&isFinite(numberOfChildren)

[@jbird4478]

6:32 You meant _or_ right?

[@brighthades5968]

6:24 has a bug: && is used instead of ||

[@turolretar]

I intentionally introduce bugs into my code and just use it and wait until it actually breaks

[@blackace1295]

My perfectionistic OCD has apparently saved me from a problem I didn't even know about. I use explicit type exclusively just because I need things to be on the same page or I'm not happy xD ::edit:: I should say, I knew about type conversion for boolean comparisons, I just never liked it. Would rather do the conversion myself manually and then run my comparisons because then I know what's actually happening. Probably means I write more code than I need to sometimes but eh.

[@yezam8608]

7:40 why not just reorganize the code to check for if(numberOfChildren) {success} else {Not success}

[@mikeonthebox]

Because 0 is still false. The example he used is terrible as the problem with that code isn't the use of ! but the fact that he is not considering the case where the number is 0.

[@yezam8608]

@@mikeonthebox u're right

[@soniablanche5672]

if user is supposed to be an object then it's fine to use if(user) {}

[@Abhilashkp]

Why can’t we use >0 ??

[@mikeonthebox]

It that case should be >= 0 and yes that would be totally fine.

[@ChrisHaupt]

typescript removes this kind of headache

[@demarcjohnson]

The great prophet Douglas Crockford told us a long time ago not to use the bang operator and we didn't listen, and now we are paying for our sins. Thanks again for bring us back to the light.

[@patitorodri]

The course are only for US?

[@WebDevSimplified]

All my courses are available globally.

[@TheSliderW]

Using an inverter in the first if() statement is already wrong in my book. Save your brain some processing time. Don't start with inverted checks. X ) Then doing boolean checks on numbers is also wrong.

[@abdulshakur2776]

Reminders that these are falsy values: "" 0 null false undefined NaN

[@mikeonthebox]

"0" also is falsy

[@CompactStar]

@@mikeonthebox Actually, it isn't.

[@yashone7]

After a while in web dev, I stopped using ! Operator and shifted to underscore to check whether something is empty or not I use _.isEmpty utility to keep my code predictable because the library I'm using takes care of so many edge cases.

[@haroldpepete]

why you jusr do a function to check when some value is considered false or true and you should call that function

[@NeroDefogger]

does anyone in the whole earth unironically code like that? I don't even want an answer I will just refuse to think there is anyone that does

[@Gastell0]

Very much not on the subject of the video, but why parseInt(input.value) and not input.valueAsNumber?

[@gillall4828]

Set min value to 1 on input, user inputs must always be limited and exhaustively validate

[@mikeonthebox]

That doesn't fix anything, can be the case for this example, where the number of children is 0

[@gillall4828]

@@mikeonthebox set to 0. That fix all the negative values, but always validade user input.

[@GonzaloMassa]

You've missed the point of the video, the issue is not about negative numbers.

[@mikeonthebox]

@@GonzaloMassa The problem is that the example he used in the video doesn't make any sense, as the use of ! isn't causing any issue as he tries to show us.

[@douglasiradukunda1451]

good

[@victorlongon]

It should use Number.isNaN(), also using Typescript would solve most of this kind of problems. I get you make videos mostly for new developers, so take the time and teach them Typescript instead

[@aleksander5298]

Number.isNaN(parseFloat(x))* ;)

[@restonthewind]

If !user is shorthand for user!=0, I don't know why that's bad.

[@ruiw4263]

Should rewrite let bool = true.

[@shramandas2721]

You should write a book on JS..

[@mikeonthebox]

This is not an error for using ! it's an error for not knowing how to deal with numbers in JS, specially with the number 0. And this is true, because even if you remove the ! from the code and invert the if/else, the code would still not work. So this doesn't make for a good example.

[@genechristiansomoza4931]

Then what would be the good example?

[@mikeonthebox]

@@genechristiansomoza4931 In my opinion, none, as there is nothing wrong with using ! if you know what you are doing. What he kinda got right is that you can use _null != something_ (That's a code style some people use and helps them with readability of code) But just saying it may turn into true something that we don't know will be false, like a 0 isn't a good example.

[@mattp0123]

I think user !== null is more noticeable than !user

[@GeorgeStamoulis81]

Yea, this is the first video I remember that I disagree with you! I like coercion for shorthands and I think it shows I know what I'm doing. Until it shows the opposite of course

[@denmarkwarrenealulod2711]

MismatchException will do.

[@trappedcat3615]

This always puts me in the twilight zone: isNaN(NaN)

[@cameron1988]

This is why you use TypeScript

[@ignaziomormando8990]

Why bang operator? I know It as the not operator

[@travelling5738]

From India🇮🇳

[@sureshnadar5335]

Just Yesterday i had this issue 😂😂

[@chairlovawitabat]

Type coercions is one of the biggest gotchas in JavaScript. Very glad that you covered this. Thank you for the excellent content! 🙏🙏🙏

[@XeroboxMedia]

Guard class. Easy in c#

[@zuhrulanam5971]

Great tutorial, love how cool js

[@federicocapucci]

why not just numberOfChildren >=0

[@mykalimba]

I'm not sure how/when/why the ! operator became known as the "BANG" operator, but I've always called it the "negation" operator. Of course, my programming lineage is along the BASIC/assembly/C/C++/C# line, so maybe that's why. And maybe this is in JavaScript only. I know that Unix refers to "!" as BANG (because onomatopoeia, perhaps?), so I suspect someone with Unix experience started working in JavaScript and carried terminology over. Regardless, I'm sticking with "negation", as that describes what the operator does. And "BANG" tells me nothing about it.

[@glimpsee7941]

NaN is Not a Number. js: `typeof NaN === 'number'` // true

[@YousefSh]

I don't think a user name will be 0

[@MrJloa]

It's perfectly fine if u did your studies with js implicit type covertions. If user is an object (class instance eg) then it will always be true or else it's not your object (class). Perfectly fine.

[@grzegorzt]

for me it is a mistake not to use a semicolon :)

[@mikeonthebox]

Agree. Otherway you may end with worst looking code where you have to put ; at the start of a line.

[@grzegorzt]

@@mikeonthebox It's not about the appearance of the code, but about errors associated with it. Run this code to see what happens: const test = 12 ['c','d'].forEach((letter) => console.log(letter))

[@RedStone576]

@@grzegorzt well obv that will throw an error but ask yourself how often do you write something like that, most people don't just write plain array without assigning it to a variable. also why use .forEach???

[@grzegorzt]

@@RedStone576 It's not about that particular code, it's just an example. I can give you dozens of such examples where there is an error when we do not use a semicolon.

[@daveisdead]

Thats why they made nullish coalescing operator

[@PabloGnesutta]

This video is absolute clickbait and it makes me mad. Making claims that "this stuff is bad... Do this don't do that", and particularly in this case, is so harmful... If you know JavaScript (or any programming language) well enough you can use the bang, or any other, operator, as you may need. Learn how things work, don't avoid stuff just because you don't understand them

[@Dev-sf3pz]

Honestly, this is just yet another reason why I despise JS. JS is the bug.

[@bagzhansadvakassov1093]

Well, what can you expect of JS - java soy language

[@threeone6012]

Q1) Does === remove much of the need for Typescript? Q2) Is it safe to say that a future version of JavaScript will include the features found in Typescript?

[@user-tx5sr2lt6z]

Clickbait...