DEV Community 👩‍💻👨‍💻

Discussion on: You don't need null

Collapse
anonyme profile image
Info Comment hidden by post author - thread only visible in this permalink
Anonyme • Edited on

Api to update profile details have several optional fields. One of them is display name.
Null = no special display name, use account name. If there was a display name, replace it with null.
Omitted = don't change display name.
String = new display name to use.

Now you just entered the realm of "let's use ugly tricks to represent null like 'empty string'" or add another field that says 'delete name'. Used empty string? Congratulations you can no longer use standard name validations (that usually occur before your api handler) because you'll get name too short or empty before even doing your ugly hack that treat empty as null.

Null have a contract meaning. Now you'll answer me like you answered everyone else "just use undefined bro" because honestly reading your comments it sounds like you dont even listen to what people try to teach you.

Go ahead, write poorly designed APIs. I'll use null, thank you.

PS and that "let's save few bytes" argument is something a junior dev would say. It's meaningless. If you really care about it use compression. Or better, use binary format and not json. But if you chose json go with proper json and don't uglify it to save few bytes. If your api use json it means you are OK with the extra overhead otherwise you wouldn't use json, and being cheap in few bytes is absurd.

That's like copy-paste the same line 10 times instead of using for, to save the for() overhead....

Collapse
lukeshiru profile image
Luke Shiru Author

Now you just entered the realm of "let's use ugly tricks to represent null like 'empty string'" or add another field that says 'delete name'. Used empty string? Congratulations you can no longer use standard name validations (that usually occur before your api handler) because you'll get name too short or empty before even doing your ugly hack that treat empty as null.

So you find "" and the type string? uglier than null and the type string | null | undefined? I guess we agree to disagree. And that second part about validations, what is that you can't validate about a string if is empty? I mean if you use null the validation might look like this:

if (displayName !== undefined) {
    if (displayName === null) {
        // use account name
    } else if (validate(displayName)) {
        // set new display name
    } else {
        // invalid new display name
    }
} else {
    // Don't change display name
}
Enter fullscreen mode Exit fullscreen mode

And look at this huge change if you used an empty string instead:

if (displayName !== undefined) {
    if (displayName === "") {
        // use account name
    } else if (validate(displayName)) {
        // set new display name
    } else {
        // invalid new display name
    }
} else {
    // Don't change display name
}
Enter fullscreen mode Exit fullscreen mode

Null have a contract meaning. Now you'll answer me like you answered everyone else "just use undefined bro" because honestly reading your comments it sounds like you dont even listen to what people try to teach you.

I mean, that being the case, you wrote a comment like everyone else pointing to this single problem with patch like APIs, when the article is about avoiding null as much as possible:

  • The article: You should avoid using null everywhere, when undefined is perfectly fine.
  • You: No, because of this particular use case.

IDK about you, but everywhere !== somewhere. And my answer is always the same because you're pointing the same thing. My answer would change if the comments where different. I explained it in the article itself, but is weird that you need to type everything as Type | null | undefined, like you need 3 different states for everything, when other languages are perfectly fine with 2 (Type | nullish).

Go ahead, write poorly designed APIs. I'll use null, thank you.

OK, go ahead and keep using it, I guess your answer to my question in the article is that because is useful in this patch like scenario, then you have to use null everywhere. I already explained that you could keep null in the contact surface with the API only, and avoid it everywhere else, but I guess that's not enough null for you 😅

PS and that "let's save few bytes" argument is something a junior dev would say. It's meaningless. If you really care about it use compression. Or better, use binary format and not json. But if you chose json go with proper json and don't uglify it to save few bytes. If your api use json it means you are OK with the extra overhead otherwise you wouldn't use json, and being cheap in few bytes is absurd.

Of course you had to go and say "You're a junior if you don't do things like I do them". JSON parsing is really fast, but skipping nullish values is faster not only because of the actual transfer from the back-end, but also because of the parsing itself. So you're making your responses smaller, your requests smaller, your parsing faster and your type checking easier, not to mention testing which doesn't need to check for 3 different types. But let's better use null because is less "ugly" and junior-like, right? 🤔

That's like copy-paste the same line 10 times instead of using for, to save the for() overhead...

Talking about for, you might not like my other article talking about it 😅

Collapse
anonyme profile image
Comment marked as low quality/non-constructive by the community. View Code of Conduct
Anonyme • Edited on

EDIT: lol you got utterly btfo so you hid my comment and blocked me from writing new comments? Coward. Hope you at least learned something.


EDIT 2: you're still a coward and continue to reply to me while I'm blocked. but you don't even worth the comment I wrote. bye.


Second reply below, before I saw you blocked and edit this:

  1. Im talking about null in js and you answer in typescript. If you want to talk about typescript say "you should not use null when using typescript". Your article seems to be talking about js and ts alike.

  2. Are you really that much of a junior that you actually write your api json validations manually with if-else, and not using a proper schema validators? Have you never written any API before or are you just being dishonest when presenting your "solution"?

  3. You wrote your article in a very strong, clickbaity tone, then you go and hide behind that tiny disclaimer in the end. Stop acting innocent. You wanted to write an edgy and controversial opinion? Own it! And if you can't or don't have the balls to do so, don't write so boldly. Just say "why you should sometimes prefer undefined over null". But that's not cool and edgy and click bait enough isn't it? So you want to eat the cake and have it too, by putting your little disclaimer in the end. Real mature.

  4. Which brings me to the next point - why I insist on putting you back in place - I know juniors like you, you try to make a name of yourself by spewing out controversial edgy nonsense that may sound like they make sense, but are actually really bad. Problem is, other juniors pick up this nonsense and repeat it to sound cool and end up writing bad code because of that. Much smarter and experienced people than you decided null was necessary. There's a reason for that. You don't have to try and butcher every holy cow just for the sake of it.

  5. Json is not extremely fast, it's extremely slow compared to pushing bytes array, but its fast enough for most APIs which makes it ok. When you choose JSON for your API you make the decision of readability over performance, and that's OK for 99% of cases because json fast enough. But if you made that decision, you don't turn back and later uglify your entire API just to do tiny optimization. That's something a junior would do. Either your API is performance critical in which case you dont use json at all, or its not in which case you try to keep it clean. I mean, you don't rename keys from 'userName' to 'un' just to save few bytes right? That's equally dumb than omitting fields that should be null, and probably save a lot more bytes. But I do hope you don't actually do that...

In summary- nulls are useful, stop trying to sound edgy then run back to your disclaimer, and you dont sacrifice readability for performance when using json.

lukeshiru profile image
Luke Shiru Author • Edited on

I know you're new here, but the community of DEV is based on respect for each other, even if you don't agree with something, you keep it respectful. You already started saying this was "ugly" and the solution was "junior", but I let that pass because you're new and maybe it was a language barrier ... but then you went and insisted with the junior thing, "lack of balls", being immature, which was more ad hominem than an actual argument. To top it all out, you added that "coward" thing when you noticed you got blocked.

If you don't want to keep getting blocked by other users or banned from DEV altogether, I suggest you lower that a notch.

Cheers!

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