Every null or undefined check doubles the number of tests you need 😱

JSK is a platform that provides tutorials, articles, and resources for JavaScript developers, covering topics such as frontend development, JavaScript frameworks, and web development tools. With contributions from industry experts and experienced developers, JSK offers insights, tips, and best practices to help developers improve their JavaScript skills and build modern web applications. Developers can learn about the latest trends in JavaScript development, explore new tools and libraries, and enhance their proficiency in frontend technologies.

css-s4hmgy.css-15e6h9m {font-family:monospace;font-size:14px;overflow-x:auto;background-color:var(--theme-ui-colors-muted);padding:16px;border-radius:4px;}.css-863l4v .comment,.css-6.5.3.1:hover, .css-7.2.3:hover,.css.8.3-3.4:hover;.css.9.4.1.0:hover.css:8.5%.css:9.5%;.css

Why null checks are bad

A null check doubles your important states

Learned something new? Want to become an expert?

Null checks are totally fine when you are 100% sure that what you check it returns null, many programing languages have core functions that return null when something fails, or if something is not found, is an old pattern.
So in the case of JS and other dynamic type languages is only a problem when you get some other falsy value you don’t expect, and if you have a large code base you could use typescript which will catch that, but generally in JS you do a check for all falsy values communally is !!value.

Hi everyone, I just wanted to say that instead of using <code>||</code> to provide a default if a value is null, it is better to use th e <code>??</code> operator. Simple case which lead to a different behavior that expected are with numbers (<code>0 || 3</code> returns <code>3</code>, while <code>0 ?? 3</code> returns <code>0</code>), strings (<code>&quot;&quot; || &quot;Unknown&quot;</code> returns <code>&quot;Unknown&quot;</code>, while <code>&quot;&quot; ?? &quot;Unknown&quot;</code> returns <code>&quot;&quot;</code>), and so on…
So remeber always to use the right operator based on the situation 😉

I’m going to disagree here with this advice. It’s too simplistic to be useful. Sure in these contrived examples, not allowing for null is helpful. But in larger projects, null is a reality. There will be optional properties within objects, and your code will need to be able to handle them. Trying to insert some default value for each optional field will result in far more complex code than simply being able to handle nulls.
Imagine you have a user object with an optional birthday field. In the user profile, you may want to show “Unknown” for the birthday, but now that means your birthday property is either a Date object or a string. Essentially you replaced null here with a magic string.
Ultimately optional properties are a reality, and pretending that they aren’t isn’t a good solution.

Awesome explanations and examples! &lt;3

I’m not really familiar with large scale React projects, but are you really supposed to test the whole component?
Maybe break a test in a bunch of tests for every variable.
For example, have generic methods for testing that would be called, like if an object has a null property, check if it contains the specific Component for when it is null.
I don’t know. I don’t think this is a problem with null checks, more so a problem with how you are developing your tests.