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

51–60 of 70 posts

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

#51

Post by cloudflare728 »

superjose wrote: post #3

I can see this. I learned from a friend to use Zod to check for process.env. I refined it a bit and got: ``` const EnvSchema = z.object({ NODE_ENV: z.enum(['development', 'production', 'staging']), DATABASE_URL: z.string(), POSTHOG_KEY: z.string(), }); export type AlertDownEnv = z.infer ; export function getEnvironments(env: Record ): AlertDownEnv { return EnvSchema.parse(env); } ``` Then you can: ``` const env = get…

Yes use zod or equivalent.

I am quite surprised people here doesn't know how to validate data in runtime. The author completely mixing Typescript with runtime behavior.

a?.b?.c?.() or var ?? something have well documented use cases and it's not what the author is thinking.

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

#52

Post by fainpul »

kbolino wrote: post #47
h1fra wrote: post #6

Earlier quoted context omitted.

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

Assuming assert existed, it would almost certainly be judging its value for being falsy , while the ?? operator judges its LHS for being nullish , which is a narrower category. For strings, this affects whether the empty string is acceptable or not.

  console.assert(maybeNull != null, 'variable not set')

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

#53

Post by MobiusHorizons »

zdragnar wrote: post #37
MobiusHorizons wrote: post #33

Earlier quoted context omitted.

I get why we prefer final in languages with a need for thread safety, but I have never understood why people prefer const in typescript. I have seen people bend over backwards to avoid a `let` even if it results in higher complexity code. It just doesn’t seem to solve a problem I’ve ever actually encountered in typescript code.

The only reason to use let is to indicate to the reader that you're going to be reassigning the variable to a new value at some point within the current scope. If you aren't going to be doing that, using const lets the reader know the assignment won't change to refer to a new value. It's that simple.

Yes, I've heard this reason before, but how does that help? The only benefit of that particular arrangement as far as I can tell is that it's possible to enforce via linter. It doesn't signal intent, it merely states a fact that could be observed by reading the source code. What is the point of that? What problem does it solve? Are people running into hard to debug issues because a variable got reassigned? I don't remember that ever causing an issue before the advent of const. People go to great lengths to avoid writing `let` just because the linters have been telling them to use `const` so they consider `let` a code smell now. Is this really better?

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

#54

Post by [deleted] »

fainpul wrote: post #52
kbolino wrote: post #47

Earlier quoted context omitted.

Assuming assert existed, it would almost certainly be judging its value for being falsy , while the ?? operator judges its LHS for being nullish , which is a narrower category. For strings, this affects whether the empty string is acceptable or not.

console.assert(maybeNull != null, 'variable not set')

[deleted]

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

#55

Post by kbolino »

fainpul wrote: post #52
kbolino wrote: post #47

Earlier quoted context omitted.

Assuming assert existed, it would almost certainly be judging its value for being falsy , while the ?? operator judges its LHS for being nullish , which is a narrower category. For strings, this affects whether the empty string is acceptable or not.

console.assert(maybeNull != null, 'variable not set')

Fair, this is a good example of when != is actually the right choice (instead of !==). However, on web browsers, this will log an assertion failure to the console, but it will not throw an exception. It's also not suitable for the original context, where the non-null value was extracted into a variable.

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

#56

Post by zdragnar »

MobiusHorizons wrote: post #53
zdragnar wrote: post #37

Earlier quoted context omitted.

The only reason to use let is to indicate to the reader that you're going to be reassigning the variable to a new value at some point within the current scope. If you aren't going to be doing that, using const lets the reader know the assignment won't change to refer to a new value. It's that simple.

Yes, I've heard this reason before, but how does that help? The only benefit of that particular arrangement as far as I can tell is that it's possible to enforce via linter. It doesn't signal intent, it merely states a fact that could be observed by reading the source code. What is the point of that? What problem does it solve? Are people running into hard to debug issues because a variable got reassigned? I don't re…

It tells you up front what you would otherwise have to go line by line to find out.

There's a similar argument to be made for using forEach/ map / reduce / filter instead of a for loop. Each of those iterative methods has slightly different semantic intent. The only thing the for loop adds to the mix, and therefore the only reason to use them, is the availability of continue / break.

Hell, the same argument could be made for while loops vs for loops. What does a for loop really add that you couldn't get with a while loop?

As for your last point, I don't know of any linter that complains about the use of let when you reassign it. The ones I've used only complain if you use let when const would have worked identically in your code.

The fact that people write bad code is not down to let/const or linters. People always have and always will write crap and not understand why.

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

#57

Post by xscott »

kbolino wrote: post #47
h1fra wrote: post #6

Earlier quoted context omitted.

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

Assuming assert existed, it would almost certainly be judging its value for being falsy , while the ?? operator judges its LHS for being nullish , which is a narrower category. For strings, this affects whether the empty string is acceptable or not.

> Assuming assert existed

It's a function you could write for yourself and give it whatever semantics you feel is best. No changes to the language required for this one.

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

#58

Post by xscott »

ameliaquining wrote: post #8
h1fra wrote: post #6

Earlier quoted context omitted.

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

There isn't a built-in assert function that behaves that way; you would need to either write it or import it.

I'm not a web dev. Are people really that opposed to writing a function which would solve problems in their project? It's two lines long...

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

#59

Post by t-writescode »

MobiusHorizons wrote: post #53
zdragnar wrote: post #37

Earlier quoted context omitted.

The only reason to use let is to indicate to the reader that you're going to be reassigning the variable to a new value at some point within the current scope. If you aren't going to be doing that, using const lets the reader know the assignment won't change to refer to a new value. It's that simple.

Yes, I've heard this reason before, but how does that help? The only benefit of that particular arrangement as far as I can tell is that it's possible to enforce via linter. It doesn't signal intent, it merely states a fact that could be observed by reading the source code. What is the point of that? What problem does it solve? Are people running into hard to debug issues because a variable got reassigned? I don't re…

> it merely states a fact that could be observed by reading the source code

In 4 characters it clarifies something that could take 300 lines, 10 nested ifs, loops, etc; and, that trust disappears the moment someone, later down in the code *does* change the value.

Clarified intent, nearness-to-declaration, and linted protection are real benefits.

Post reply on HN