-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Synthetic fold #30
Comments
totally, I wrote my comment there you can close this 👍 |
While I agree with that issue that we should keep |
So there're 2 ways of implementing such fold: export const fold3 = <E, A, R>(
onNone: () => R,
onFailure: (e: E) => R,
onSuccess: (a: A) => R,
): ((fa: RemoteData<E, A>) => R) => fold(onNone, onNone, onFailure, onSuccess);
export const fold3_ = <E, A, R>(
onNone: (progress: Option<RemoteProgress>) => R,
onFailure: (e: E) => R,
onSuccess: (a: A) => R,
): ((fa: RemoteData<E, A>) => R) => fold(() => onNone(none), onNone, onFailure, onSuccess); And therefore we have 3 questions:
|
I'm in favor of the latter if we have to pick one since it provides more capability, but I also think there's a case to be made that both could be useful. If we support both, maybe we could rename the parameters to
I was wondering the same. I wonder if it would be nice to just be fairly verbose/explicit and name it something like
IMO yes. Although it's simple and everyone could add it to their own prelude in their own project, given #10 suggests this situation is quite common for most people, I think it should just be part of this lib. But if it feels clunky for some reason, I'm open to the counterargument |
Hi everyone, nice to see this picked up again :)
I think the second implementation maps better to current implementations / doesn't remove potentially important functionality
I kinda like it actually, it has a "mathy" flavour :)
I still think this is relevant for the ergonomics of the package, I think it is important enough to live in the core |
Ok guys, feel free to send a PR for this :) |
hi @raveclassic,
first of all, thank you for this piece of code, it defines a very complete and clean interface for dealing with IO data.
In most of the apps I design, when I fetch data the
initial
case does not need to be handled (data is fetched as soon as a view is loaded so I want to handle only theloading
,failure
andsuccess
cases). As this is true for 95% of my use cases, it seems a bit overkill tofold
on my data structures as it forces me to handle separately theloading
andinitial
case but at the same time, I would like to keep the strictness for all other cases.How would you feel about a
syntheticFold
method that merges the handling ofinitial
andloading
?The text was updated successfully, but these errors were encountered: