Beefed up `call()` function. about effection HOT 4 CLOSED

This is one area that I feel pretty confident saying: users are not going to want to think about converting their promises into operations everytime they want to activate one inside a DC. It's not that much of a lift to support officially and the ergonomics make a ton of sense.

The bigger issue for me is supporting both safe and unsafe call() functionality. I built a safe() function that is the same as call() but wraps the call inside a Result type. This is extremely useful for cases where a user wants to run parallel operations and collect the results (e.g. starfx parallel).

It works but integrating both into a single API seems better.

from effection.

This is one area that I feel pretty confident saying: users are not going to want to think about converting their promises into operations everytime they want to activate one inside a DC. It's not that much of a lift to support officially and the ergonomics make a ton of sense.

I agree, and our test cases we actually do this https://github.com/thefrontside/effection/blob/v3/test/suite.ts#L7-L16 However, I am very nervous about monkey-patching the global Promise prototype.

Is opt-in going to be still too awkward? Maybe we make it opt-out?

It works but integrating both into a single API seems better.

How would we integrate this into a single call() API since the type of the return value is of a different for safe calls?

from effection.

However, I am very nervous about monkey-patching the global Promise prototype.

Why do we need to monkey-patch? starfx has call() that supports promises oob. What about that don't you like?

from effection.

Oh, I thought you were saying we should be able to yield to promises

yield* someAsyncFunction();

vs

yield* call(someAsyncFunction());

from effection.