DEV Community

Discussion on: You don't need null

View post

Replies for: How can use less ""features"" makes something lead to bugs? The only way of leading to bugs is if a dev assumes that something will have a null val...

 
loucyx profile image
Lou Cyx • • Edited

Do you actually do if (matches === null) nowadays? You don't need a wrapper. You can use nullish coalescing and avoid a lot of pain with both null and undefined (again, you handle both cases the same way). So you can do something like this:

const [match] = "bar".match(/foo/) ?? [];

console.log(match ?? `Not found`);
Enter fullscreen mode Exit fullscreen mode

Which works with both null and undefined. Instead of having to write:

const matches = "bar".match(/foo/);

console.log(matches !== null && matches[0] !== undefined ? matches[0] : `Not found`);
// or relying on falsy
console.log(matches && matches[0] ? matches[0] : `Not found`);
Enter fullscreen mode Exit fullscreen mode

And I still don't see where the distinction between null and undefined is valuable here. With the same example of the util, if someone does a wrapper of something that generally returns undefined, and they make it return null, it could cause confusion as well. You should't code assuming the nullish output of a function, and you still can be resolved similarly to the above issue.

BTW, if I had to write a wrapper for match, I would do it something like this:

const match => regExp => string => string.match(regExp) ?? [];
Enter fullscreen mode Exit fullscreen mode

This way you can not only curry it, but always be sure you'll receive an ArrayLike from it instead of RegExpMatchArray | null which is far from ideal.

 
scottshipp profile image
scottshipp •

Do you actually do if (matches === null) nowadays?

It seems that you asking this question proves the point. You have no idea what I (or other clients of your code) are going to do. I may do that or use the fact of matches returning null (and not undefined) in probably a few dozen different ways. And when/if you change that, you introduce the potential for bugs, as previously pointed out.

You don't need a wrapper.

The idea of a "wrapper" came from your comments, not mine, though.

And I still don't see where the distinction between null and undefined is valuable here. With the same example of the util, if someone does a wrapper of something that generally returns undefined, and they make it return null, it could cause confusion as well.

I am not sure but I'll give the benefit of the doubt here and assume that you are not willfully missing the point. So to reiterate again: yes that could cause confusion as well, and the very fact of this confusion is why JavaScript developers should not ask "Do I really need to use null?" and should, instead, use both null and undefined consistent with general practice. It is the standard practice (the idiom) in JavaScript for null to represent a purposefully-set value and undefined to represent a value that was never set, and this is in the language specification as well as the canonical books and documentation.

 
loucyx profile image
Lou Cyx •

It seems that you asking this question proves the point.

My point was that you shouldn't assume the output of a function. In your previous comment you basically said that you "expect" something to return null. Based on your same logic in this new comment: "You have no idea what I (or other clients of your code) are going to do", so why is bad for me to assume you'll know that you shouldn't do matches === null, but is good for you to assume that the function will return null instead of actually checking the return type of the thing you're using?

And when/if you change that, you introduce the potential for bugs, as previously pointed out.

But that's the thing, if you use a function assuming it will return either null or undefined, why is it on me as the dev and not on you as the consumer of that function? I already said this, but the other way around your same argument applies, if you create a function that I expect will return undefined, and instead you decide that it will return null, then it's my problem that I was expecting your function to return something I wanted it to return, instead of checking the typing or using something like ??.

And I still don't see where the distinction between null and undefined is valuable here. With the same example of the util, if someone does a wrapper of something that generally returns undefined, and they make it return null, it could cause confusion as well.

I am not sure but I'll give the benefit of the doubt here and assume that you are not willfully missing the point.

Trust me, I'm giving you the same benefit. I added sources to the article for y'all to explore, because my personal experience of not using null in personal projects and at work, and not missing it at all, and explaining that the "distinction" between intentionally missing and unintentionally missing value is pointless because they are both missing and need to be dealt with the same way. Maybe checking some other sources besides my article adds some light to the subject, but if null is so necessary, how is it that Angular is considering dropping null, TypeScript doesn't use null in its source, and folks like Douglas Crockford, with years of experience in JS, don't use null at all and just use undefined instead?

As @darkwiiplayer pointed out several times already, that "need" for multiple nullish values is trivial, having 1, 2 or 10 different nullish values with differences you define with conventions, doesn't take back the fact that they are all still just nullish.

Every time I ask: Why do you need to do that distinction?

The answer is pretty much "because null exist in JavaScript for that", but that doesn't actually answer the question. There are several things that exist in JS to be used for something, and we realized that there are better ways to do that same thing and not use that feature (eval and with are the two that I mention constantly).

We might never agree on this, but the questions I leave to you are:

Do you actually tried to code without null at any point? Do you ever worked with a library/framework or codebase without null and missed having it? Because I sure did tried doing it "your way" in the past, and once I did the "transition" I never went back.

Some comments have been hidden by the post's author - find out more