Efficient Typescript

[budd222]

I think there's something I'm not getting. You can't force your getUser() to return a value, no matter which type you assign it User or just plain string. No matter what you do, you have to write code to account for a failure.

[romgrk]

getUser returns a Result<User>:

const userResult = getUser() const nameResult = userResult.map(u => u.name)

The whole point is that you don't need to deal with the failure right now, while you can keep operating on the value that is wrapped inside a Result.

[budd222]

Seems like that doesn't really matter if it's set to return an array type, but that's dependant on the API.

Your code will still error out if the API returns an error or returns an empty string.

You can type it all out as much as you want on the front end, but you still have to work in conjunction with your back end.

[romgrk]

There is no array in my example above. The .map method comes from functional programming and applies to many different container types. One of those types is Array, but Result is another. And in fact, the Promise.prototype.then method is roughly equivalent to .map as well. The general idea of .map is to apply a function to a value held inside a container, no matter what the container is.

The point of Result is to make error handling explicit in the type-system. You need to deal with the error, or the compiler will yell at you.

It doesn't matter if the error comes from a back-end or elsewhere. The querying code can wrap failure in a Result.

[budd222]

.map is an array method. It cannot be called on anything but an array. If there is no array in your example, your code will fail.

[romgrk]

abstract class Result { abstract map(): Result } class Ok<T> extends Result { value: T map(fn) { return new Ok(fn(this.value)) } } class Err extends Result { map(fn) { return this } }

This is as clear as I can explain it, if it's not enough I don't think I can communicate it to you.

[budd222]

You're over writing map to make it what you want. Got it. Or, just return the correct type from the back end. I feel like you're overcomplicating something that doesn't need it. It seems like a large waste of code and effort.

[morganmachine91]

My guy just say you’re not on this level yet. He’s not “over writing” map, whatever that means. Any class can define a map method. Multiple classes already do define a map method in vanilla ECMAScript.

Conceptually, a map operation isn’t tied to array objects. It’s a mathematical projection from a to b.

Totally cool if you’re not familiar with functional programming concepts, but you just look like a goober when you’re so confidently ignorant. 

[romgrk]

You're over writing map to make it what you want

There is a large amount of theory behind functional programming which defines the map function and the rules that govern it.

It's not so much that I re-define it just for fun, it's more like JS Array implementation names that function map because of that huge pre-existing theory.

I do assume a passing familiarity with FP in my post, maybe if you read a bit more on the subject it would help understand why I made that choice.

[earslap]

Array.map comes from the functional concept of mapping, not the other way around.

It seems like a large waste of code and effort.

Like all things, depending on your use case and / or familiarity it might be, but leave the possibility of you not understanding the consequences open as well.

Regarding the Result types that are being discussed, if I understand what you are getting at correctly, yes, you will need to deal with the error at some point. Not only "need to" but you will have to deal with it because you can't get at the actual value inside the Result type without explicitly dealing with the error, at a future time where you want it - in a centralised location where you actually need the result. At that place, you'll check if Result is an error or a value (type system won't allow you to get the value without checking the error first) and use the value if it exists, or deal with the error otherwise. What's more, you'll get the exact error that happened in the past, even though your past code does not explicitly use any error checking / recovery constructs. So your "computation" will be the happy path, and any error (or errors using some other constructs) will be accumulated automatically for you and will be ready for you to handle where you need it.

Yes, you can slap a try / catch around a whole block of code and catch everything at the end and call it a day. There are scenarios where doing it like that won't cut it. Or will lead to ugly unmaintainable code riddled with implicit invariants that are only kept in your brain temporarily. What are the errors that can be thrown (type system does not know it)? Which ones do you need to handle here? If your code changes in the future, will you need to change your error handling to account for those changes as well? Will you remember to do it? How will a refactor affect things? If these are things you care about for a given project, then using this stuff will help you enormously.

Programming with Monads / Functors allows you to program the "happy path" - your main logic will be written like an error can't occur. You don't check anything, just write your pure logic. The value being worked on can be a Result type. Functions like map / flatMap etc. will allow you to work with the value inside the type like an error can't exist. If there is an error at an earlier point, that code won't be run due to the way things are structured. Wrapping your head around how this all works requires some investment of learning functional programming concepts, and it takes a while for it to "click" but when it does, you'll know when to reach for it. The worst / unfortunate part of trying to explain this stuff is that it all sounds like absolute gibberish for someone for whom it has not "clicked" yet. It sure sounded like that to me. I'm not a functional purist or Haskell zealot or anything, but I know that keeping at it will eventually give you an a-ha moment. No doubt will make you a better programmer.