[Discussion] Task, Either, TaskEither

[ceuk]

Hi @chriskrycho, huge admirer of your (and the other contributors) work.

I've taken a load of your project structure, which is great and copied forked your Maybe class but added three others: Task, Either and TaskEither.

I've literally just finished this second so it's still pretty early days and I don't plan to invest much in making the package usable by others, it's just got some stuff I wanted. They're much more lightweight than your two as well, as I've only focused on what I considered essential.

However, due to how similar these are in coding style and implementation I was wondering if you'd be interested in me drafting a PR around one or more of the additions? It wouldn't take too much work on my part. Got 100% test coverage, just need to add some doc-friendly comments and would have to potentially adapt task to use Result instead as that might make more sense. Plus whatever else you felt was needed.

Anywhoo, you can have a look here if you want to check it out. If you think there's something useful there let me know :)

Cheers

[chriskrycho]

@ceuk thank you and so sorry for the delay! I at least am definitely interested (and would love to hear @bmakuh’s thoughts). I’d be happy to coordinate async here or to set up a sync discussion in chat or a video call sometime.

[bmakuh]

Oh wow very nice! @chriskrycho and I have talked about adding a Task before, but it's never happened. Just taking a glimpse, it does look pretty similar. Out of curiosity, could you describe your motivations for splitting apart Task and TaskEither? (And we've generally opted for the language of Result instead of Either following languages like Elm). Chris and I are curious about the use case of a Task that doesn't handle errors.

[ceuk]

Hi both, to answer some of the above:

I went with the name Either because it's what I was already using, but I'm more than happy to adopt your nomenclature.

Regarding my motivation for splitting Task and TaskEither, I was thinking when I wrote them that you might not want to have to deal with the Right around your response (maybe the handler is from a third-party lib and you'd have to write a proxy fn just to grab the value from the Right), or that maybe you wanted two pathways that weren't driven by a throw (TaskEither is opinionated in that it doesn't let you dictate how it decides whether to use a Right or Left - it's just a try/catch. This is fine if the library/API you're using throws when it should, but I didn't want to encourage people to be writing first-party code that throws errors in order to return a Left)

In practice, the only thing I use it for currently is when I'm handling the response more-or-less straight away because it's easier and cleaner to call fold or fork and pass in my success/error handlers than it was to call await x.run() and then fold on the resultant Either. However, as I'm typing this I've just realized I should just implement afold method onTaskEither and that would solve the issue.

On @chriskrycho's point about synchronous coordination, it might be nice to have a chat about the current state of things etc as I imagine quite a few little things to cover and we could bash through them in a single call.

What would your ideal next steps be?

[chriskrycho]

Let's get something set up for sometime in April – feel free to email me at hello@chriskrycho.com and I'll get it set up!

As a brief summary of my current thinking, in the meantime:

• I'd love to land a variant of this in True Myth! It would resolve Idea: Task #25 quite nicely. 😂

• I think what I'd want to do is: use TaskEither and just name it Task. One of the primary advantages of a Task over a Promise, in my view, is that it allows you to capture the failure mode. In the case where you know it to be non-fallible, you can always make it Task<T, never>, and that's fine.

• We'd obviously want to make the APIs match!

• I think we'd also, related to the second bullet there, want to make sure that a Task.fromPromise API would handle the failure mode, something roughly like this type-signature wise:

  declare class Task<T, E> {
    static fromPromise<T>(promise: Promise<T>, onErr: (unknown) => E);
  }

  That means that when you do Task.fromPromise you end up doing something like this:

  declare let promise: Promise<number>;
  let task = Task.from(promise, (err) => {
    if (err instanceof Error) {
      return err.message;
    } else if (typeof err === 'string') {
      return err;
    } else {
      return JSON.stringify(err, null, 2);
    }
  })

  This would produce a Task<number, string>. And again, if you want a fallback to unknown or never, that's easy enough to do; in fact you could make a version of that which just supplies id and therefore gives you back Task<number, unknown>.

If that all sounds reasonable to you, let's get something going!

[ceuk]

Sounds good to me!

On the fromPromise method, this the the current implementation

export function fromPromise <L, R> (promise: Promise<R>): TaskEither<L, R> {
  return new TaskEither((resolve) => promise
    .then((r: R) => resolve(Either.of(r)))
    .catch((l: L) => resolve(left(l))))
}

Would an optional second arg (onErr) that functions as above work do you think? e.g. (overloads, currying etc omitted for brevity)

export function fromPromise <R, L = unknown> (promise: Promise<R>, onErr?: (err:unknown) => L): TaskEither<L, R> {
  return new TaskEither((resolve) => promise
    .then((r: R) => resolve(Either.of(r)))
    .catch((l: L) => resolve(left(onErr ? onErr(l) : l))))
}

Edit: (imagine Right = Ok and Left = Err)

I'll drop you an email with some availability on April - this should be fun :)

[jansedlon]

Hello guys, I noticed this library got a new release, maybe bumb this discussion?