`Promise` doesn't provide variants of `catch` and `either` where the rejection function returns another `Promise` about fable-powerpack HOT 6 CLOSED

Ok, I understand :)

Seems fine to me. Just either type signature which looks complex :)

from fable-powerpack.

I was not aware of the existence of the "erased cast" operator, and my chief concern was with the awkwardness of inserting U2.Case1 everywhere, but now I that I know that the operator exists, I think that we should fix the signature of either instead of adding eitherBind. The justification is that either probably represents "advanced" usage, and therefore it is both more rare in existing code and practiced by more experienced developers, who wouldn't be confused by the changed signature as much.

By the reverse reasoning, and agreeing with @alfonsogarciacaro, I agree with adding catchBind.

from fable-powerpack.

I think that's a good idea! Though maybe the signature of eitherBind should be the following? (So success also returns a Promise.)

let eitherBind (success: 'T->Promise<'R>) (fail: Exception->Promise<'R>) (pr: JS.Promise<'T>): JS.Promise<'R> = jsNative

I know this reduces flexibility, maybe we could do something like this, although it may not be very pretty:

let eitherBind (success: 'T->U2<'R,Promise<'R>>) (fail: Exception->U2<'R,Promise<'R>>) (pr: JS.Promise<'T>): JS.Promise<'R> = jsNative

We could use the !^ operator for combination (for example, return a non-promise in success and a promise in fail):

myPromise
|> Promise.eitherBind (fun x -> !^(string x)) (fun ex -> !^(Promise.lift ex.Message))

from fable-powerpack.

Hum, I am asking myself if it's a good idea to add "custom" methods in the libs instead of fixing it. If I understand correctly, we are less permissive than the official API.

The compiler should, generate an error when the user update it's deps and so help him identified and fix the errors.

from fable-powerpack.

@MangelMaxime In principle you're right, but we must be careful with this, because it's always annoying to find that your code is not compiling anymore after updating a dependency and sometimes it's difficult to figure out how to fix the error right away.

In any case, we need to decide if we do need to fix this and how. It's true the JS API (.then) is more flexible than the F# one, but I think it's OK to have two methods (map and bind) because they're standard in most functional languages. For catch, I'd say it's also OK to have both catch and catchBind for similar reasons.

The trickiest part is either as it allows four combinations (non-promise/non-promise, promise/promise, non-promise/promise, promise/non-promise). If we decided to go for the ('T->U2<'R,Promise<'R>>) -> (Exception->U2<'R,Promise<'R>>) -> JS.Promise<'T> -> JS.Promise<'T> signature, it may make sense to directly modify either, yes (though it's a breaking change).

from fable-powerpack.

It seems we reached an agreement ;) @fsoikin Would you mind sending a PR to modify the signature of Promise.either? Ideally adding an explanation in the help comment on how to use the !^ operator. Cheers!

from fable-powerpack.