Synthetic fold

[Federico Sordillo]

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 the loading, failure and success cases). As this is true for 95% of my use cases, it seems a bit overkill to fold on my data structures as it forces me to handle separately the loading and initial 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 of initial and loading?

[Kirill Agalakov]

@fes300 Well this is completely related to #10

[Federico Sordillo]

totally, I wrote my comment there you can close this 👍

[Steven MacCoun]

While I agree with that issue that we should keep initial, still seems to me it would be useful to have this syntheticFold idea you propose for situations when we want to treat initial and pending as identical. Does that method exist? If not, this issue still feels relevant as #10 is debating removing it, while this issue could be about providing a utility method to improve ergonomics for a "common case"

[Kirill Agalakov]

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:

• which one should we pick?
• what name should we pick? fold3 looks weird
• is it worth adding such one-liner to the core?

[Steven MacCoun]

which one should we pick?

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 onPending for fold3 and onProgress for fold3_?

what name should we pick? fold3 looks weird

I was wondering the same. I wonder if it would be nice to just be fairly verbose/explicit and name it something like foldPendingOrReplete for fold3 and foldProgressOrReplete for fold3_, but I admit those feel a little clunky. We could also call it foldIgnoreInitial, but tbh I could live with a simple name like fold3 as I think it is still fairly clear what it does.

is it worth adding such one-liner to the core?

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

[Federico Sordillo]

Hi everyone, nice to see this picked up again :)
here are my 2cents:

which one should we pick?

I think the second implementation maps better to current implementations / doesn't remove potentially important functionality

what name should we pick? fold3 looks weird

I kinda like it actually, it has a "mathy" flavour :)

is it worth adding such one-liner to the core?

I still think this is relevant for the ergonomics of the package, I think it is important enough to live in the core

[Kirill Agalakov]

Ok guys, feel free to send a PR for this :)