Instance method `.toEither` about remote-data-ts

[sutarmin]

I would keep toOption because there are cases.
Consider we have UI component which accepts value wrapped into Option and just renders a placeholder if the value is none. Now we want to render data from API using this component. Without toOption we would have:

value.fold(none, none, () => none, some); // ugly

So it does make sense to me.
The same for toEither, there could be cases.

I believe the question here is "Do we want to have close integration with other fp-ts ADTs from inside of RemoteData?". My opinion is "yes" because RemoteData is implemented over fp-ts and if you are using remote-data-ts you are likely using fp-ts by itself.

[raveclassic]

@scotttrinh Well the main goal of this project is to be 100% typesafe, not to force some design patterns. It should be up to developer how to use RemoteData so I think it's ok to provide such API. Would you like to oper PR?

[raveclassic]

@scotttrinh How would you represent RemoteInitial and RemotePending?

[scotttrinh]

Excellent question. 🤔

Maybe the signature would require a function for each of those two cases?

toEither: <L, A>(initial: () => Left<L> | Right<A>, pending: () => Left<L> | Right<A>);

Totally contrived example:

data.toEither<string, Resource[]>(
  () => left('No data loaded'),
  () => right([])
);

Perhaps not all that helpful? Easy enough to make a separate function for each case.

[raveclassic]

Could you please describe your usecase? Do you really need to convert RemoteData context to less powerful Either? Even existing toOption/toNullable seem to be a bad practice because they allow you to drop parts of the context.

[scotttrinh]

I use toOption all of the time when I want to do the same thing to initial/pending/failure and another to success. My thought around toEither is to have something in between that can account for failure separately.

Like I said, it's easy enough to create this as a function, so if it's not in scope for this library, that's fine. Just figured since toOption already existed, a similar toEither might be helpful.

[raveclassic]

I use toOption all of the time when I want to do the same thing to initial/pending/failure and another to success.

Could you provide an example? Seems like either we don't use toOption in our codebase at all or such places are considered deprecated and invalid because of unnecessary context destruction.

The problem is that toOption was introduced to replicate Either API from fp-ts and is now considered bad practice (in our codebase). Even more I believe it should be deprecated.

/cc @mankdev @sutarmin

[raveclassic]

@sutarmin This is incorrect because you should use renderRemoteData to render RemoteData instead of destroying the context.

This is not the question of integration because Either.toOption is absolutely valid as the value of Either (or error) is always resolved while RemoteData context adds an unresolved state to the value. IMO such case should not be treated as None because RemoteInitial and RemotePending describe unresolved states.

[scotttrinh]

To be fair, I'm using a fork of this library with an additional state, RemoteRefresh, that kind of acts like a RemotePending but with (potentially stale) data. I'm considering adding the toEither method in my fork, and want to offer it "back upstream".

My current use-case involves setting data to pending | refresh depending on whether there is existing data, which I do constantly.

As I readily admitted before, either of these is pretty easily accomplished as a function instead of an instance method that just calls #fold for the consumer:

toOption: <L, A>(data: RemoteData<L, A>) => Option<A>
toEither: <L, A>(data: RemoteData<L, A>, initial: () => Left<L> | Right<A>, pending: () => Left<L> | Right<A>);

[scotttrinh]

IMO such case should not be treated as None because RemoteInitial and RemotePending describe unresolved states.

I would say that the idea of mapping between domains and loosing structure is a pretty common practice, so I don't personally have a problem with that. Const, for instance, is an example of something useful that maps everything into a single value. Not a big deal if it's not an instance method since the ergonomics of using a function is just as good, and this doesn't need access to some hidden internal state.

[scotttrinh]

I'd be happy to open a PR. Do you think the fold-like behavior for mapping the initial and pending states makes sense? You could also just have a single function or value that represents both states.

[raveclassic]

@scotttrinh I think if we distinguish RemoteInitial and RemotePending then we should also processs them separately. A method signature could be:

toEither: RemoteData<L, A> ~> (initial: Lazy<L>, pending: Lazy<L>) => Either<L, A>

[raveclassic]

Or even:

toEither: RemoteData<L, A> ~> (initial: L, pending: L) => Either<L, A>
toEitherL: RemoteData<L, A> ~> (initial: Lazy<L>, pending: Lazy<L>) => Either<L, A>

[scotttrinh]

@raveclassic

Oh, I like having toEither and toEitherL! Do we think it's necessary that initial and pending have type L or could it be L | A?

[scotttrinh]

Do we think it's necessary that initial and pending have type L or could it be L | A?

Nevermind! The extra runtime overhead and complexity isn't worth the extra flexibility, and there are often cases where L and A are the same type, so initial and pending both mapping to Left<L>.