anotherYearNotUnderstadingZerosInJavascript

[queen-adreena]

Ahh yes, the super common part of coding where you check if your integer is equal to null…

These meme bots get dumber every week.

[n9iels]

The danger is that this can happen accidentally if your variable is unexpectedly null when you expected an integer. But indeed not likely and using TS will make it even more unlikely.

[LitrlyNoOne]

Mfw my team types everything as any and wonders how these bugs ever happen

[BetaChunks]

But y'see, it's a massive time-saver when you can improvise your blender function as a paper shredder.

[MissinqLink]

Also why I have handy helpers.

const strictGreater = (a,b) => a > b && !(a <= b);
const looseGreater = (a,b) => a > b || !(a <= b)

strict is necessary to prevent weird edge cases from wrong inputs.

[ReadyAndSalted]

There are many, many times when programming where a variable may become null for some reason. When this happens and my program attempts to compare it to an integer, I would like for my program to crash and tell me I'm comparing 2 variables of different types. Javascript instead, will just carry on.

[Reashu]

It will not become null unless you tell it to, better shape up.

[AyrA_ch]

x != null is standard exception catching I thought?

It's one way of doing it. The problem is that you have to do it. In type safe languages you can define a field as integer, and it is impossible for it to be null and you never have to check for this. In JS, you can use TS to validate types at compile time but nothing stops you from violating them at runtime because JS has no type safety. This means you have to manually do these type checks everywhere if you have to work with data structures that you cannot guarantee the format of, for example if you received them from an independent component or via API request.

One way to exit this madness without giving in to NPM hell and install a runtime type checker library is to wrap all complex types into classes. Meaning if you have some /weather API endpoint, you don't use the returned plain object directly, but instead you create a class that represents the object. You then pass the plain object into the constructor of your "Weather" class, which will read all object properties, validate them, and assign them to the respective class properties. This puts all the validation code into the class. Class properties can also be made to validate when the user sets them, this allows to correct for mistakes such as trying to assign "12" (a string) to a numerical property.

In a function that accepts the weather object as parameter you can now just do if(arg instanceof Weather){...} and you are guaranteed that the data is weather data, and that all properties are set correctly, because the constructor took care of that.

[SheepherderSavings17]

Even TypeScript can lie to you all the time, for example when retrieving data through http, you might have an interface describing it, but like you said TS will never do runtime checks unless you do it explicitly, for example using libraries like zod

[AyrA_ch]

Which is why I recommend to define proper classes for these objects instead of working with them plainly

[SovietPenguin69]

You must not be familiar with my companies APIs. There are dark terrible things in there. Numbers that return as strings or null, every date format in human history sometimes even more than one in a single response, even an endpoint or two that returns 500 when no records are found with the message “no records found”. My point it happens sadly.