I couldn't figure out the purpose of using neverthrow or the idea behind this approach. There was no information about it in the project repository either. Then I came across your video, and everything immediately became clear. Thank you!
I'm glad it was helpful! The important thing it to understand the principle, the library you use is not that important. Heck, you can implement the Result type on your own too! ;)
Thanks for the video, completely agree on the topic. Just wanted to point out that there is no need to use a library. It's enough to return a discriminated union type like Response = { type: 'error', reason: string } | { type: 'success', data: T }
Have you had a chance to get acquainted with the "ts-belt" library? This is a library for TypeScript providing Option & Result types, but also other flavors from functional programming. And most interestingly, the source code of this library is written in Rescript! :)
I didn't know about this library, thank you for sharing! But as I read ts-belt, the first thing I thought about was Rescript's Belt :) I'll give it a go.
I like the idea of Either/Result types, because it clearly separates what is happy and sad path. However, I am curious your thoughts of just returning original value type and an Error? For example, safeParseInt would return int | Error vs Result. I have been littering code bases with this and it has proven useful, and I am actually not sure when it would be desired or wanted to return an Error type in the happy path, so I don’t see the benefit of separating the sad path out. Is there other benefits to wrapping in Result type I don’t see?
Thank you for your comment! Generally speaking, for safeParseInt there are indeed just two outcomes - either int or Error (with only one possibility for sad path - 0). So, it's okay to return int | Error. However, the Result type help to turn a partial function (not defined for all inputs) into a total function (defined for all inputs), by returning a value of type Result instead of int (for example). Notice that the Result type takes two generics - Result and can be constructed in two ways - Ok or Err. However, the Error generic can hold another ADT for all possible outcomes (in more complex cases). For example, a file system operation can fail for a number of reasons - all of them can be defined as an ADT (by the way, same is true for the happy outcomes). This situation would be a bit cumbersome to describe without any differentiation mechanism - int | FileNotFound | BadPath | FileLocked | Whatever. Compare this to Result. On top of that, sometimes, there are cases where your function may return int | int - but which one is which? All in all, I'd say that it's a good practice to stick to a single code style - either throwing exceptions, or int | Error, or Result type. Mixing them will lead to confusion in the team. However, if I have a choice, I always use the Result type. I hope it all makes sense :)
![BOWKYLION - วิงวอน (ex-change) [Official MV]](http://i.ytimg.com/vi/cLdnZWDaO-w/mqdefault.jpg)
![[#2024MAMA] G-DRAGON - 무제(Untitled, 2014)+POWER+HOME SWEET HOME+뱅뱅뱅+FANTASTIC BABY | Mnet 241123 방송](http://i.ytimg.com/vi/Ox29z5Nf1Uk/mqdefault.jpg)
I couldn't figure out the purpose of using neverthrow or the idea behind this approach. There was no information about it in the project repository either. Then I came across your video, and everything immediately became clear. Thank you!
I'm glad it was helpful! The important thing it to understand the principle, the library you use is not that important. Heck, you can implement the Result type on your own too! ;)
@@BeyondTypeScript Yea! You are totally right
Thanks for the video, completely agree on the topic. Just wanted to point out that there is no need to use a library. It's enough to return a discriminated union type like Response = { type: 'error', reason: string } | { type: 'success', data: T }
Completely agree!
Have you had a chance to get acquainted with the "ts-belt" library? This is a library for TypeScript providing Option & Result types, but also other flavors from functional programming. And most interestingly, the source code of this library is written in Rescript! :)
I didn't know about this library, thank you for sharing! But as I read ts-belt, the first thing I thought about was Rescript's Belt :) I'll give it a go.
I like the idea of Either/Result types, because it clearly separates what is happy and sad path. However, I am curious your thoughts of just returning original value type and an Error? For example, safeParseInt would return int | Error vs Result.
I have been littering code bases with this and it has proven useful, and I am actually not sure when it would be desired or wanted to return an Error type in the happy path, so I don’t see the benefit of separating the sad path out.
Is there other benefits to wrapping in Result type I don’t see?
Thank you for your comment! Generally speaking, for safeParseInt there are indeed just two outcomes - either int or Error (with only one possibility for sad path - 0). So, it's okay to return int | Error.
However, the Result type help to turn a partial function (not defined for all inputs) into a total function (defined for all inputs), by returning a value of type Result instead of int (for example). Notice that the Result type takes two generics - Result and can be constructed in two ways - Ok or Err. However, the Error generic can hold another ADT for all possible outcomes (in more complex cases). For example, a file system operation can fail for a number of reasons - all of them can be defined as an ADT (by the way, same is true for the happy outcomes). This situation would be a bit cumbersome to describe without any differentiation mechanism - int | FileNotFound | BadPath | FileLocked | Whatever. Compare this to Result. On top of that, sometimes, there are cases where your function may return int | int - but which one is which?
All in all, I'd say that it's a good practice to stick to a single code style - either throwing exceptions, or int | Error, or Result type. Mixing them will lead to confusion in the team. However, if I have a choice, I always use the Result type. I hope it all makes sense :)
Recommend you switch to `neverthrow` as `ts-results` is unmaintained
Thank you for the suggestion! Indeed, there are lots of alternatives to `ts-results`.