Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Abuse of the nullish coalescing operator in JS/TS

fredrikmalmo.com

Post reply on HN
Print view View original

11–20 of 70 posts

Re: Abuse of the nullish coalescing operator in JS/TS

#11

Post by ameliaquining »

GMoromisato wrote: post #5

Is this a weakness in the type definition? If we're sure the value cannot be undefined, then why doesn't the type reflect that? Why not cast to a non-undefined type as soon as we're sure (and throw if it is not)? At least that would document our belief in the value state. I may not understand.

If your type definitions are airtight then this problem doesn't come up, but sometimes, for whatever reason which may not be entirely within your control, they aren't. Narrowing and failing early is precisely what the article advises doing.

Re: Abuse of the nullish coalescing operator in JS/TS

#12

Post by noman-land »

slooonz wrote: post #9
polishdude20 wrote: post #7

Earlier quoted context omitted.

Exactly, something like a name missing shouldn't cause the app to completely error out for the user.

Yes it should, because hopefully errors are logged and reported and can be acted upon. Missing name doesn’t.

Why not both?

Re: Abuse of the nullish coalescing operator in JS/TS

#13

Post by t-writescode »

h1fra wrote: post #6
ryanpetrich wrote: post #4

Should throw expressions ( https://github.com/tc39/proposal-throw-expressions ) ever make it into the JavaScript standard, the example could be simplified to: const env_var = process.env.MY_ENV_VAR ?? throw new Error("MY_ENV_VAR is not set");

so like assert(process.env.MY_ENV_VAR) but in a less readable oneliner?

Since JS doesn’t have if statements return values, null chaining is a great way to keep both const variables and have some level of decidability.

Null chaining is also a common pattern across most languages and is generally seen as readable

Re: Abuse of the nullish coalescing operator in JS/TS

#14

Post by jackblemming »

h1fra wrote: post #6
ryanpetrich wrote: post #4

Should throw expressions ( https://github.com/tc39/proposal-throw-expressions ) ever make it into the JavaScript standard, the example could be simplified to: const env_var = process.env.MY_ENV_VAR ?? throw new Error("MY_ENV_VAR is not set");

so like assert(process.env.MY_ENV_VAR) but in a less readable oneliner?

That doesn’t assign it to the shorthand local variable.

Re: Abuse of the nullish coalescing operator in JS/TS

#15

Post by SkiFire13 »

> Personally, I've come to see this ubiquitous string of symbols, ?? "", as the JS equivalent to .unwrap() in Rust

It's funny you bring this up because people opposed to `.unwrap()` usually mention methods like `.unwrap_or` as a "better" alternative, and that's exactly the equivalent of `??` in Rust.

Re: Abuse of the nullish coalescing operator in JS/TS

#16

Post by pitched »

slooonz wrote: post #9
polishdude20 wrote: post #7

Earlier quoted context omitted.

Exactly, something like a name missing shouldn't cause the app to completely error out for the user.

Yes it should, because hopefully errors are logged and reported and can be acted upon. Missing name doesn’t.

If the error isn’t repairable by the user, blocking them from using the app entirely is mean. If the error screen has a message telling the user where to go to set their name, that’s fine but annoying. If the error screen tells the user they can’t use the app until someone checks a dashboard and sees a large enough increase in errors to investigate, that’s a bigger problem.

Re: Abuse of the nullish coalescing operator in JS/TS

#17

Post by rustc »

noman-land wrote: post #12
slooonz wrote: post #9

Earlier quoted context omitted.

Yes it should, because hopefully errors are logged and reported and can be acted upon. Missing name doesn’t.

Why not both?

That's how you get this feature: https://wiki.php.net/rfc/deprecate-bareword-strings.

tldr: undefined constants were treated as a string (+ a warning), so `$x = FOO` was `$x = "FOO"` + a warning if `FOO` was not a defined constant. Thankfully this feature was removed in PHP 8.

Re: Abuse of the nullish coalescing operator in JS/TS

#18

Post by jackblemming »

slooonz wrote: post #9
polishdude20 wrote: post #7

Earlier quoted context omitted.

Exactly, something like a name missing shouldn't cause the app to completely error out for the user.

Yes it should, because hopefully errors are logged and reported and can be acted upon. Missing name doesn’t.

This reads like a dogmatic view of someone who hasn’t worked on a project that’s a million plus lines of code where something is always going wrong, and crashing the entire program when that’s the case is simply unacceptable.

Re: Abuse of the nullish coalescing operator in JS/TS

#19

Post by ameliaquining »

SkiFire13 wrote: post #15

> Personally, I've come to see this ubiquitous string of symbols, ?? "", as the JS equivalent to .unwrap() in Rust It's funny you bring this up because people opposed to `.unwrap()` usually mention methods like `.unwrap_or` as a "better" alternative, and that's exactly the equivalent of `??` in Rust.

Semantically the two are kind of opposite; the similarity is that they're the lowest-syntax way in their respective languages to ignore the possibility of a missing value, and so get overused in situations where that possibility should not be ignored, leading to bugs.
Post reply on HN