Better asynchrony Support

[Marius9595]

The current version (v1.1.0) of the library supports Asynchrony but it needs another level of wrapping: Promise<Monad<value|description>>

On the other hand, some operations cannot be performed (map or flatmap) as sync processes.

We are thinking some approaches to improve this. But you can contribute with your ideas :D

Our main constrain is not breaking any contract, and we would like something easy to understand

[Wolfremium13]

Hello, how's it going? I was thinking about trying to support the interoperability of Either functions, which are synchronous, with Future functions. For this, I was inspired by the .toAsync method from LanguageExt.Core, which allows converting an Either into one that supports asynchrony. In our case, we have the Future component. Here's an example case:

  it.each([
    {
      type: 'Right',
      either: Either.right(2),
      syncClosure: (x: number) => x * 2,
      asyncClosure: async (x: number) => x * 2,
      expected: 8,
    },
  ])(
    '$type should handle map with another async map operation correctly',
    async ({ either, syncClosure, asyncClosure, expected }) => {
      either
        .map(syncClosure)
        .toPromise()
        .map(asyncClosure)
        .complete(
          async (value) => expect(await value).toEqual(expected),
          async (error) => expect(error).toBeUndefined()
        );
    }
  );

Where in abstract class we add:

// abstract class Either<L, R>
abstract toPromise(): Future<R | L>;

And in its implementations:

// class Left<L, R>
toPromise(): Future<L> {
    return Future.of(() => Promise.resolve(this.value));
}

// class Right<L, R>
toPromise(): Future<R> {
    return Future.of(() => Promise.resolve(this.value));
}

I'm no expert in this field, but I find it interesting to be able to chain synchrony with asynchrony, giving the latter the possibility to have previous asynchronous calls. Let me know if you have any feedback.

[Marius9595]

Hi @Wolfremium13!

Thanks for your proposal! :D

The approach is interesting. To keep something like the pipeline of transformations you propose is something that we want to.

The usage of Future sounds good because we could avoid the duplication of monads such as Either with EitherAsync. Although I am a little concerning about some method names:

• I would say toAsync instead of toPromise. I would maximize the essential instead of the implementation detail.
• complete is something distinct to Either Context, probably it makes sense because we are dealing in this case with async stuff. But it is personal feeling because I would like something that keeps the match contract, but I think without duplication is not possible.

What do you think @myugen? This proposal allows creating a pipeline of transformation with sync and async stuff, for me the main requirement.

[myugen]

I really like the proposal! I was thinking, that maybe we might be more explicit and call the new method toFuture(), since we are talking about monads, not concepts. What do you think?

[Marius9595]

Makes sense. In addition an interface comes to my mind to align each monad that could be futureable or something like that

[myugen]

That seems reasonable to me, so, does any futurable monad needs to implement toFuture() method?

[Marius9595]

Exactly. In this way we could create a test suit as we did with monad and matchable interfaces