I keep wondering about a type system where you can say something like "A number greater than 4" or "A string of length greater than 0" or "A number greater than the value of $othernum". If you could do that, you could push so much of this "coping" logic to only the very edge of your application that validates inputs, and then proceed with lovely typesafe values.
Abuse of the nullish coalescing operator in JS/TS
31–40 of 70 posts
Re: Abuse of the nullish coalescing operator in JS/TS
#32It seems Rust's unwrap is the exact opposite of ?? "". It throws an error instead of using a fallback value, which is exactly what the author suggests instead of using ?? "".
Yes that was a mistake.
unwrap() is the error.
unwrap_or() is the fallback.
Re: Abuse of the nullish coalescing operator in JS/TS
#33Earlier quoted context omitted.
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
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.
Re: Abuse of the nullish coalescing operator in JS/TS
#34I keep wondering about a type system where you can say something like "A number greater than 4" or "A string of length greater than 0" or "A number greater than the value of $othernum". If you could do that, you could push so much of this "coping" logic to only the very edge of your application that validates inputs, and then proceed with lovely typesafe values.
https://en.wikipedia.org/wiki/Refinement_type
Thank you - I didn't know it had a name. But I'm not surprised it came from ML.
Re: Abuse of the nullish coalescing operator in JS/TS
#35I keep wondering about a type system where you can say something like "A number greater than 4" or "A string of length greater than 0" or "A number greater than the value of $othernum". If you could do that, you could push so much of this "coping" logic to only the very edge of your application that validates inputs, and then proceed with lovely typesafe values.
Your can do that now in Typescript. But it will take several minutes to resolve your types. I've done it and it's a horrible dev experience, sadly.
Re: Abuse of the nullish coalescing operator in JS/TS
#36I use this operator all the time in a similar but not quite the same way:
The user is an entity from the DB, where the email field is nullable, which makes perfect sense. The input component only accepts a string for the defaultValue prop. So you coalesce the possible null to a string.
Re: Abuse of the nullish coalescing operator in JS/TS
#37Earlier quoted context omitted.
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
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.
Re: Abuse of the nullish coalescing operator in JS/TS
#38I keep wondering about a type system where you can say something like "A number greater than 4" or "A string of length greater than 0" or "A number greater than the value of $othernum". If you could do that, you could push so much of this "coping" logic to only the very edge of your application that validates inputs, and then proceed with lovely typesafe values.
You can do it in typescript with branded types:
https://effect.website/docs/schema/advanced-usage/#branded-t...
There is some ceremony around it, but when you do the basic plumbing it's invaluable to import NonEmptyString100 schema to define a string between 1 and 100 chars, and have parsing and error handling for free anywhere, from your APIs to your forms.
This also implies that you cannot pass any string to an API expecting NonEmptyString100, it has to be that exact thing.
Or in e-commerce where we have complex pricing formulas (items like showers that need to be custom built for the customer) need to be configured and priced with some very complex formulas, often market dependent, and types just sing and avoid you multiplying a generic number (which will need to be a positive € schema) with a swiss VAT rate or to do really any operation if the API requires the branded version.
Typescript is an incredibly powerful language, it is kinda limited by its verbose syntax and JS compatibility but the things that you can express in Typescript I haven't seen in any other language.
Re: Abuse of the nullish coalescing operator in JS/TS
#39Re: Abuse of the nullish coalescing operator in JS/TS
#40[deleted]