An Option type in TypeScript (inspired by Rust)

[joshuayoes]

I works at a company where all the SDKs for HTTP clients used an Either type from fp-ts. Honestly, I loved it.

The only pain point I've run into with it is consuming third party library code when a lot of your core domain logic is bought into this style of error handling. You need to write a lot of adapters to get the benefits in this case. However, it was a good fit for these SDKs since we owned most of the types

[mkvoq]

It is kinda pointless for languages where you can have NULL values.
I think it is more sensible to use monads here, avoiding null/type checks whatsoever.

[hansschenker]

Andrew is becoming a Typescript Ninja! Thank's for publishing!!

[j-wenning]

An option type is a bit redundant when you're using strict null checking. A lot of the utility here is pretty much duplication of things TS already does for you.

const x: number | null = 123;

const doSomething = (val: number) => { console.log(x / 2) };

// examples of "unwrapping" x
doSomething(x!);
doSomething(x as number);
doSomething(x as any);

if (x !== null) {
// within this block, x is not null (None), do whatever
}

const xVal = x ?? 123; // fall back to a default value

[rendezone]

Amazing job Andrew. Btw, ES2019 has optional catch binding, so you wouldn't need the errors if you're returning none;

[lm-gnxr]

TypeScript with enabled null-safety (strictNullChecks option, which is enabled by default) already has Option types, `type Option<T> = T | null` is an Option type so you can just use `T | null` instead of your construct

[slava_in]

I'v been using `Result<T, E>` with `Ok()` and `Err()` in TS mimicked from Rust lately, and I love it, such a great solution for error handling.

[DemanaJaire]

I feel like concepts like monoids, monads, functors, pure functions are not discussed enough in the context of FP, and it always amazes me when some programmers claim to be functional programmers, and yet never heard of these concepts.

[mageprometheus]

Thanks Andrew. I was thinking about this last week and you have done all the hard work.

[marcialabrahantes]

Go's approach of multiple returns is much cleaner, and it doesn't overcomplicate the function typing signature...

the way you handle the response is the same essentially

[Elator]

Thank you Andrew. Glad I found your channel! Your videos are very insightful, looking forward to more videos on typescript!

[MarquisKurt]

Nice! Reminds me of how Optional types work in Swift.

[reedlaww]

I like rust. But in the context of JS/TS it doesn’t make sense IMO. Falsey/truthy values already exist as first-class types in the language. Approaches like this just add more noise to the call stack IMO.

[mjdev-ip]

Kinda pointless since typescript supports optional chaining

function getSomeString() : string | undefined{ /* .... */ }
const someStr : string | undefined = getSomeString();
someStr?.split(' ').forEach( () => /* ... */ );

This also works with objects using the Partial<T> interface

[david.baierl]

This only makes sense when you realy need an empty value beside of null/undefined (for not even calculated). otherwise you should simply use the strict null check to avoid adding more unessesary complexity to your codebase.

[cristobaljavier]

Great video, I've been thinking about this myself, your presentation was excellent.

[ikhito]

Amazing video, thank you! Looking forward to more.

[santhoshd]

Implementation of Either as in Scala would have been ideal. Option is better suited for nullable types.

[malvoliosf]

Andrew discovers monads in 10... 9... 8...

[Azoraqua]

Good suggestions. Mind you, you could define the `getTimeDiff ` signature as `dates: [Date, Date]` and then it would only allow two dates, and you can even use the destructuring syntax to get those;

```
function getTimeDiff(dates: [Date, Date]) {
const [start, end] = dates;

return end.getTime() - start.getTime();
}

const diff = getTimeDiff([date1, date2]);
```