Abuse of the nullish coalescing operator in JS/TS
fredrikmalmo.com
Abuse of the nullish coalescing operator in JS/TS
1–10 of 70 posts
Re: Abuse of the nullish coalescing operator in JS/TS
#2In general, I agree. You don’t want silent failures. They’re awful and hard to reason about.
> By doing this, you're opening up for the possibility of showing a UI where the name is "". Is that really a valid state for the UI?
But as a user, if I get a white screen of death instead of your program saying “Hi, , you have 3 videos on your watchlist” I am going to flip out.
Programmers know this so they do that so that something irrelevant like my name doesn’t prevent me from actually streaming my movies.
Re: Abuse of the nullish coalescing operator in JS/TS
#3I 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 = getEnvironments(process.env);
```
`env` will be fully typed!
Definitely, I need to do some improvements in my frontend logic!
Re: Abuse of the nullish coalescing operator in JS/TS
#4Should 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");Re: Abuse of the nullish coalescing operator in JS/TS
#5Is 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.
Re: Abuse of the nullish coalescing operator in JS/TS
#6Should 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?
Re: Abuse of the nullish coalescing operator in JS/TS
#7In general, I agree. You don’t want silent failures. They’re awful and hard to reason about. > By doing this, you're opening up for the possibility of showing a UI where the name is "". Is that really a valid state for the UI? But as a user, if I get a white screen of death instead of your program saying “Hi, , you have 3 videos on your watchlist” I am going to flip out. Programmers know this so they do that so that…
Exactly, something like a name missing shouldn't cause the app to completely error out for the user.
Re: Abuse of the nullish coalescing operator in JS/TS
#8Should 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?
There isn't a built-in assert function that behaves that way; you would need to either write it or import it.
Re: Abuse of the nullish coalescing operator in JS/TS
#9In general, I agree. You don’t want silent failures. They’re awful and hard to reason about. > By doing this, you're opening up for the possibility of showing a UI where the name is "". Is that really a valid state for the UI? But as a user, if I get a white screen of death instead of your program saying “Hi, , you have 3 videos on your watchlist” I am going to flip out. Programmers know this so they do that so that…
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.
Re: Abuse of the nullish coalescing operator in JS/TS
#10In general, I agree. You don’t want silent failures. They’re awful and hard to reason about. > By doing this, you're opening up for the possibility of showing a UI where the name is "". Is that really a valid state for the UI? But as a user, if I get a white screen of death instead of your program saying “Hi, , you have 3 videos on your watchlist” I am going to flip out. Programmers know this so they do that so that…
This is a fine line. If you get a white screen of death you know something is wrong. If the first name is missing it may mean other things are missing and the app is in a bad state. That means the user could lose any work they try to do, which is a cardinal sin for an app to commit.
Context matters a lot. If it's Spotify and my music won't play is a lot different than I filled a form to send my rent check and it silently failed.