Intent to stop using null in my JS code

[sindresorhus]

I intend to stop using null in my code, in favor of undefined. There are many reasons for doing so.

Feedback wanted

Tweet: https://twitter.com/sindresorhus/status/1114894287387258886

Background

http://2ality.com/2013/05/history-undefined.html

Reasons

• From experience, most developers use null and undefined inconsistently and interchangeably, and few know when to use which.
• Supporting both null and undefined complicates input validation.
• Newer JS features like default parameters only work with undefined.
• typeof null === 'object'.
• I strongly believe it was a mistake to have two have both null and undefined.
• Using null makes TypeScript types more verbose: type A = {foo?: string | null} vs type A = {foo?: string}.

Problems

• We cannot remove null from JavaScript

True, but we can pretend it doesn't exist (in most cases). And we can enforce no null usage with linters.

• We cannot change browser and Node.js APIs that accept/return null.

That's fine. At least we can improve user-land code.

• JSON doesn't support undefined

We just have to live with that. We could implement a custom JSON.parse/stringify that handles the conversion.

Resources

• https://medium.com/@oleg008/what-if-we-stop-using-null-d705302b545e
• TSLint rule to disallow null
  (I intend to enforce this when typescript-eslint ports this rule)
• https://stackoverflow.com/questions/36201110/why-do-functions-return-undefined-instead-of-null-by-default
• No need for 2 "absence representations" DavidBruant/ECMAScript-regrets#26
• https://twitter.com/brendaneich/status/617450289889607681?lang=en
• https://twitter.com/brendaneich/status/330775086208524288

[youbiak]

Other resource I found about this topic :

• Douglas Crockford thinks null is a bad idea and we should all just use undefined.

[jsynowiec]

Something can be defined, but allowed to be null (see it as a "no value" state). It’s different than just undefined. Especially with TypeScript and you’re even mentioning it a bit in the last point.

Using null makes TypeScript types more verbose: type A = {foo?: string | null} vs type A = {foo?: string}.

foo: string | null has different meaning and use than foo?: string

I’m interested in your thoughts about this difference. Don’t you encounter cases when you can benefit from it?

[jonahsnider]

type A = {foo?: string} is also not the same as writing type A = {foo: string | undefined} when exactOptionalPropertyTypes is enabled

[atesgoral]

Since let got introduced, I started using null to give a dummy value to my variables, just because let something; reads like an unfinished sentence:

let x; // let x what?

let x = null; // oh so, we'll set it to something better later

The reason I don't use let x = undefined; is, well, it's functionally the same as just let x;, and only human-grammatically different. I find initialization to null to be an explicit promise to set the value later.

[eps1lon]

Feedback wanted

Don't know if you care about what other libraries do but React's ref objects for instance are declared as type Ref<T> = { current: null | T }. null is used here as the default value i.e. React.useRef().current === null.

type A = {foo?: string | null}

Using null as the bottom value might be interesting if you care about property existence. If you declare { foo?: string } you don't know if the value of foo might be undefined or if the the object doesn't have a property foo. If you want to explicitly communicate via types that property foo exists and might have a bottom value then null is kind of your only option

[joakimbeng]

How do you reason about nulls in a database when used together with JS? E.g. an SQL database. Do you propose that undefined is translated to and from null when writing to/reading from the database?

[paulmillr]

Screw null and undefined, we should just switch to Maybe monad. 🤗

[yannbertrand]

I tend to use undefined as an unknown state e.g. when waiting for an HTTP response.

I have been using null as an unset value e.g. a not-filled input but I never feel the need to use it as I could be using an empty string in most cases instead.

[felixfbecker]

A couple of thoughts:

JSON doesn't support undefined

It does for properties: JSON.parse(JSON.stringify({ foo: undefined })).foo === undefined.
It only doesn't for array elements, but in all my time writing JS/TS I've never encountered a use case for JSON arrays with holes.

Another point: Many of the modern JS APIs return undefined for "doesn't exist", e.g. array.find().

I'm personally not super strict with not using null, when working with the DOM API for example I use null because that's what DOM APIs return, and when working with databases the distinction between a null value and an unknown value (i.e. wasn't SELECTed) can be useful. But in general, I prefer undefined. Especially with TypeScript it saves a lot of boilerplate code.

[tipakA]

I find this comment fascinating, because it very nicely points out the ambiguity of undefined.

> JSON.parse(JSON.stringify({ foo: undefined })).foo === undefined
true
> JSON.parse(JSON.stringify({ foo: undefined })).foo
undefined
> JSON.parse(JSON.stringify({ foo: undefined })).bar
undefined
> JSON.stringify({ foo: undefined })
'{}'

Your foo: undefined never even made it into the JSON in the first place, for i guess obvious reason:

JSON doesn't support undefined

[igghera]

I quit using null more than an year ago and i never felt the need for it.

[ricardohbin]

About this custom JSON.stringify/JSON.parse:

The main problem with currently undefined fields disappears in actual scenario is when a JS service needs to provide/receive JSON code to other languages - and all of them supports "null", not "undefined".

For example, if the custom converter works like:

JSON.parse(JSON.stringify({a: undefined})) // {a: undefined}

It will only works in js world. This is a problem when working principally in backend between a lot of services with different languages.

To custom JSON.parse, you can do an override null to undefined like python does with None, but to JSON.stringify, we need to make sure undefined turns in null.

Ex:

JSON.stringify({a: undefined}) // '{"a":null}'
JSON.parse('{"a":null}') // {a: undefined}

Makes sense?

[mcmire]

I'm curious why you're choosing to use undefined over null? To me, null is a more meaningful value than undefined. If something is undefined, then it's not set yet. But why should that be possible? Everything should be initialized to something, even if it's nothing. And if I want to initialize something to nothing, then null seems like the more semantic option of the two.

Or is this less about semantics and more about pragmatism?

[medikoo]

To me it looks more as a TypeScript problem that put you in that weird corner.

In 99.999% of validation cases, treating both null and undefined same way as no value, is what will work perfectly. If TypeScript makes that difficult, then it's a problem to be addressed there.

[ljharb]

I don’t think it matters what you use in your own code - what matters is that you treat null and undefined the same as input.

Also, the cost of needing custom JSON tooling seems pretty understated.

[nanodracula]

I switched to use only undefined when it's possible about half a year ago. Never regret it.

[MarkTiedemann]

I used undefined only for a while. But I'm back to using both now. I find that worrying about this kind of consistency was impacting my productivity more than any supposed gains. Sometimes, I think it's best to accept that the world is messy...

Or ditch both null and undefined, and use void this instead - it definitely sounds cooler.

[benjamingr]

Hey Sindre, this is "trending" in hacker news in case you're wondering why a year old issue is suddenly getting attention.

https://news.ycombinator.com/item?id=24956156

[symbioquine]

I don't have a strong opinion, but there are a few arguments which don't seem to have been presented yet;

• "null" less than half as long as "undefined" and can be typed one handed if you use QWERTY. Even the first four letters require fewer finger movements since two of the letters are the same.
• null as a keyword for a missing no-value reference seem to be more common across languages than "undefined".

[jimmywarting]

do you want something as equally short as null (4 letters) and can be written using the same right hand side of the QWERTY keyboard with only one hand and using the same amount of 3 different characters to avoid moving you little finger to an 4th key and don't like to type out the hole word undefined? try 0..o or ''.o 🙃

[Indomitable]

Actually my opinion is exactly opposite: To stop using undefined and to use only null. For me undefined in more like system type while null is more user type. undefined has double meaning, the check type obj.x === 'undefined' it maybe the x prop is missing or x prop is available with value undefined. Object.keys will return different results in both cases. It is possible to code without using the word undefined. So when I do a code review I always encourage devs to replace undefined with null.

[Indomitable]

Imagine you are writing a library and you expose an interface

interface ISomething {
  param?: string;
}

Then this library is consumed from by another dev, who see, that param is an optional property so he decides to use
'param' in obj where obj is ISomething. If in your library you assign undefined to the param then the consumers may have bug, because 'param' in obj will be true.
So don't forget there is a huge difference between

interface ISomething0 {
   param?: string
}
interface ISomething1 {
   param: T | undefined;
}
interface ISomething2 {
  param: T | null;
}
// Sometimes i see even: 
interface ISomething3 {
  param?: T | null | undefined;
}

I would never use ISomething1 or ISomething3 declaration, unfortunately TS doesn't make a lot of difference between 0 and 1.
Here is another example of using undefined which can cause problems: Optional parameters in functions. Many JS libraries use arguments in functions to create overloads. there is a lot of JS code that look like:

function do(param0, param1?, param2?)  {
     switch(arguments.length) {
        case 1:  {
             // use only param0
        },
        case 2: {
           // use param0 and param1
        },
        case 3: {
           // use param 0, param 1 and param2
        }      
}

A developer who is used to use undefined as NO VALUE, may invoke function like do(1, undefined, '2) which immediately will bring bug in his code.

[Indomitable]

functions like Array.prototype.find return undefined which means there is no value found. What if you have code like: [1, 2, undefined, 0].find(x => !x) your code will return undefined you may assume there are no Falsy values in your array but it is quite opposite: you have 2 of them undefiend and 0

[lafiosca]

@Indomitable Your several examples here feel contrived and seem to indicate anti-patterns to me.

First, regarding the library exporting the ISomething interface, given that we're in the realm of TypeScript, I contend that the developer using 'param' in obj to check for the type of obj.param is in the wrong. If I write TypeScript code like that, it won't work:

interface OtherThing {
    a: number;
    b?: number;
}

const getDoubled = (e: OtherThing) => {
    if ('b' in e) {
        return e.b * 2; // error here
    }
    return e.a * 2;
}

Specifically, TS will highlight an error on the e.b: Object is possibly 'undefined'. (2532). The existence of the property b does not imply that it is not undefined. (Now if you're arguing that we should not use undefined because you disagree with this aspect of TypeScript's semantics, that's perhaps a separate issue.)

As a side note, in contexts not involving object literals directly, TS interfaces only specify the minimal subset of properties. Other keys you might not expect can be "in" an OtherThing, and of course TypeScript will not infer their types. For example:

const x = { a: 3, b: 5, c: 'extra' };
const y = getDoubled(x); // this is fine
console.log('c' in x); // outputs true

In your next example you say there is a huge difference between ISomething0 and ISomething1 but that TS doesn't make a big difference between them. I'm not sure what you mean by this. In my experience, TS treats these quite differently. For example:

interface Something0 {
   param?: string
}

interface Something1 {
   param: string | undefined;
}

const a0: Something0 = { param: undefined }; // this is fine
const b0: Something0 = {}; // this is fine

const a1: Something1 = { param: undefined }; // this is fine
const b1: Something1 = {}; // TS complains

TS will complain about b1 with this error: Property 'param' is missing in type '{}' but required in type 'Something1'. (2741)

Regarding your third example about the variadic function breaking when undefined is passed explicitly as a middle argument to a library function, it seems like this would be a mistake in the implementation or documentation of the library, or a mistake in the usage of the library. It's not clear to me from the example what specific bad behavior you're anticipating here, nor how it implies we should not use undefined.

Regarding your final example, you are correct, although again it feels very contrived to me. As a developer I need to be aware that the standard implementation of Array.find returns undefined when the item is not found, I need to be cognizant of whether the data might contain undefined values, and probably I should be using something like Array.findIndex instead for cases like this. But we would have run into a conflict like this regardless of what value the implementation used to indicate a missing element simply because JS arrays can contain elements of any type. In other words, if they had decided that Array.find would return false when an item was not found, then I would have run into this issue with any array containing false as an element. (If this became a serious enough issue for me, I would consider creating a new find method which returned a composite object indicating whether the item was found or not and including the value when it was found.) I do not feel like this is a compelling reason to prefer using null over undefined in most of my code, particularly because this exact issue could still come up when consuming an array which I did not construct, from another source such as a library.

Now for the full disclosure of where I'm coming from here...

I'm primarily a TypeScript developer right now. Perhaps about a year ago, I found this thread and the discussion around it, and my immediate reaction was "NO, undefined and null have very distinct, albeit subtle, meanings! I use them both depending on context!" But I read the various arguments and decided, "Ok, I'll give this a shot for a bit, as an experiment, and see how I feel about it." I stopped using null in my own TS code (other than when JSON/APIs are involved), and I have to admit I have not missed it at all. In particular, undefined is a lot friendlier with TypeScript code than null is, for the reason that it's used implicitly with TS's optional values. I have not run into a single contrived scenario where I felt hamstrung by this decision in a year of writing TypeScript every day, including front-end code (React Native mobile and React web), back-end code (Lambda/Express REST API services using SQL databases), open-source libraries for public consumption as modules, and various side projects.

I've remained subscribed to this issue since then, to see if anyone came along with more compelling arguments (in either direction), and it's been pretty amusing to see the sudden burst of activity. With the barrage of gut disagreements coming in, I wanted to chime in from the perspective of someone who really appreciated @sindresorhus bringing up this suggestion and has found it valuable in their own work. Thank you.

[fregante]

functions like Array.prototype.find return undefined which means there is no value found. What if you have code like: [1, 2, undefined, 0].find(x => !x) your code will return undefined you may assume there are no Falsy values in your array but it is quite opposite: you have 2 of them undefiend and 0

Looks like a classic example of "but this one weird case" that nobody really needs. Why would you need to find undefined or null in an array? If you're checking for its existence, use .some or .every with negation.

[Indomitable]

First I think the high activity is due to the recent publication in "Hacker News".
When I have

interface X {
    p?: string;
}

const v : X = { 
    p: undefined
};

I have problem with Typescript, because this shouldn't be allowed, in this case p is optional prop, not a prop that can contain undefined, if I wanted otherwise I would write:

interface X {
    p: string | undefined;
}

I really don't like that undefined has two meanings: 1: missing property and 2 no value.

@fregante This is just an example and in this case I search for the first "Falsy" value, not if there is value or not. By returning undefined I can not figure it out is undefined in the array or there are no "Falsy" values.

[fregante]

@fregante This is just an example and in this case I search for the first "Falsy" value, not if there is value or not. By returning undefined I can not figure it out is undefined in the array or there are no "Falsy" values.

Whichever nullish value you prefer, unless you can ensure that only one exists, you need account for both either way. The first solution that comes to mind is to use findIndex instead of find.

[NicBright]

I'm 100% on the same page with @sindresorhus -- I've opened up a feature request for the Angular code base to abandon null in favor of undefined. If you're an Angular user, I'd be very happy if you could have a look at it and up/downvote according to your preferences (this is, because Angular feature requests will only be considered if they get more than 20 upvotes in a 60 day-period).

Thanks and Best Regards, Nic

[leaumar]

There's two aspects to this discussion tbh. One is what you do with your projects (thread title), which should be driven entirely by maintenance burden and user friction. The other is the more general discussion this thread has become about avoiding null everywhere.

On the first topic, I'd say do you what find makes your projects the safest, most usable, and most maintainable. People who aren't in both sets of shoes (user & maintainer) can't really evaluate all those things well.

On the second topic:

Everyone uses null and undefined inconsistently and interchangeably.
Nobody really knows when to use which.

Uh, no, not "everyone" and "nobody". These aren't arguments to stop using either one, only observations that many[citation needed] js devs lack some important knowledge/experience to make a reasoned choice.

[JaccoGoris]

as far as I know, you can't clear a state from useState, in react, by doing setState(undefined) because it works the same way as just calling setState(). For obvious reasons, calling setState without data is ignored. avoiding null would break this feature in react.
Null is also more deliberate than undefined. It makes it clear to other programmers that you intend it to be null, and not that you've just left it without initializing.

[sindresorhus]

It makes it clear to other programmers that you intend it to be null

null is used for all kinds of purposes in the wild. Seeing null does not always make it clear what the behavior will be. For example, in Node.js streams, null is used to end the stream: .push(null).

When I'm saying "don't use null", I'm not saying you have to replace it with undefined.

In the React and Node.js case, it would IMHO be better to use a dedicated method with an clear name. That would make the intent obvious. For example, clearState(). Even a Symbol would be better than null: setState(React.resetState).

[lafiosca]

I set useState values to undefined all the time and have never encountered a problem. Both buttons in this example work fine for me: https://stackblitz.com/edit/react-ts-7hak7x?file=index.tsx

[patroza]

undefined is modeled just fine in JSON: absence of the key, which very well models undefined as abscence of data/specification.
null universally means the empty value. At various places it's important to model absence. Think of a patch api, absence of a key means not changed.
There are other ways to model those though, if you model changes as an array, then the absence within the array, would achieve the same :)
You can workaround null by using a null-object pattern or alike, but I rather just stick to the language features to model absence vs empty value.

[leaumar]

In my work, we've clearly settled over time on the following regarding null/undefined:

• as inputs, they're equivalent
• all our nullish checks are == null for safety, shortness, and familiarity
• as outputs/returns, we use the quickest and most convenient thing available, which often happens to be undefined as the value of an unset property or implicit/blank return; statement, but we'll just as well return null if that happens to be more straightforward

We've had constructions where they were distinct and served different purposes, but we refactored that away again soon enough and used a meaningful Symbol to represent deletion in that situation instead.

[Ghirigoro]

undefined and null have distinct semantics (i.e. undefined means absent, while null means explicitly set to empty). In a dynamic language it's very useful to be able to distinguish between cases where something is structurally missing and where something is not initialized/set. I'm very consistent about using null and undefined and it helps me in debugging (i.e. knowing that I failed to set a value as opposed to knowing that I got the wrong type of object). You might disagree and find that the debugging and other help is not worth the complexity of supporting two semantically similar types. So I think reasonable people can disagree about whether they should use null or not, but I think it's less reasonable to say that null is universally bad and should never be used.

[patroza]

Yea null being a billion dollar mistake is just in languages that have non explicit nullable types. A mistake that’s being rectified in various languages like typescript and newer c# :)