-
-
Notifications
You must be signed in to change notification settings - Fork 590
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Optional
type
#31
Comments
@EladBezalel What about |
I'd make a separate type |
Sorry about this but when I think about a Any ideas for a less overloaded name? |
And just looking at the type, it is so trivial that it actually sacrifices readability in favor of saving a few keystrokes. Now, everyone reading this has to look it up instead of directly and unambiguosly understand it. This is a clear NAK from my side. @sindresorhus has the final word on it. |
As far as i see it it's very self explanatory, once you find out that type you understand it and use it. As for the naming i wanted something that implies - you either get T or get nothing |
If we were to add it, I would call it I've been wanting this type since I started using TypeScript. I also initially found it surprising that I would strongly encourage you to open an issue on TypeScript about adding this type. |
I use a Maybe as a result type for quite a few of my utility functions that are designed to return undefined if certain conditions aren't met. I usually define it as It's all semantics, of course, but for result types I prefer |
I have reconsidered and I think we should add this. While I wouldn't recommend using it in reusable packages, and I think we should clearly discourage it for open source projects, it can be a nice utility for large internal projects where everyone knows what it means. It would also be nice to have it here as an example on how to implement it correctly. And it can be a good way to push TypeScript to add it if more people are exposed to its usefulness and start using it in their code. I think we should go for: type Optional<T> = NonNullable<T> | undefined; Alternatively: (Which inlines type Optional<T> = T extends null ? never : (T | undefined); Opinions on which? I'm leaning towards the latter. If you wanna do a PR for this, please read https://github.com/sindresorhus/type-fest/blob/master/.github/contributing.md thoroughly and look at previous PR additions. |
FWIW I like type Nullable<T> = T | null | undefined; Which is just the exact opposite of I typically don't mind having the type as const upper = (str: Nullable<string>) => str ? str.toUpperCase() : null;
interface Obj {
foo?: string;
bar: string | null;
}
const obj: Obj;
upper(obj.foo);
upper(obj.bar); |
Thanks for the link. I know what I'll be thinking about the rest of the day 😉 |
Has this happened? |
The issue is still open. |
@sindresorhus didn't you outline your own thoughts on this here: What else is there to do? |
The actual work. The issue is accepted, but someone has to take the time to write a description, high-quality docs, examples, etc. |
@BendingBender Optional: should only mean it can be defined or not (undefined) Metaphor: I have received no letter (undefined) vs I've received an empty letter (null), both are different concept, but the outcome is still "I've nothing to read", this is precisely why we (sadly) don't really pay attention to either one or the other. Therefore (#318): type Nullish = undefined | null;
type MaybeNullish<T> = T | Nullish; or Maybe<Nullable<T>> |
An optional type is really missing in the context of return types,
When a function might a value or not you find yourself piping undefined
Can be really useful
The text was updated successfully, but these errors were encountered: