Closed GregOnNet closed 1 year ago
Hi,
today I was facing this use case again.
This time ResultAsync
was involved, that's why I wrote an async version of tryRecoverIfFailure
.
Not sure if this is the best possible implementation. I post both implementations here, for documentation purpose.
export function tryRecoverIfFailure<TValue, TError>(projection: FunctionOfT<Result<TValue, TError>>): ResultOpFn<TValue, TError, TValue, TError> {
return (result) => {
return result.isFailure ? projection() : result;
};
}
export function tryRecoverIfFailureAsync<TValue, TError>(
projection: FunctionOfT<ResultAsync<TValue, TError>>,
): ResultAsyncOpFn<TValue, TError, TValue, TError> {
return (resultAsync) => {
return ResultAsync.from(resultAsync.isSuccess.then((isSuccess) => (isSuccess ? resultAsync.toPromise() : projection().toPromise())));
};
}
Short Update:
In my project, I renamed the operators to:
This naming makes clear that the projection-function expects a ResultAsync.
I'd take a PR for those 👍 - I like the name and I think they could be useful to more developers.
That's great to read.
You can assign me to this issue. I will prepare the PR. 🥳
@seangwright, PR #22 available
Resolved with #22
Is your feature request related to a problem? Please describe.
condtion_1
&condition_2
got extracted into own functions, returning aResult
.condition_1()
succeeds, use its Result, otherwise executecondition_2()
I was not able to figure out how to achieve this with the built-in operators. Maybe I am thinking too procedural, here?
Describe the solution you'd like It would be nice having an operator, allowing to execute a function that returns a Result, if the predecessor-Result is a failure.
Describe alternatives you've considered
tryRecoverIfFailure
Additional context I am wondering if it is beneficial to add an operator to the library's core. Possibly there is already a better way, I am not able not see.
Thank you so much, Cheers Gregor