question about representing "pending+data" state

[giogonzo]

Have you avere considered adding a case representing a state where we have some data (success or failure that is) and also we are re-fetching a remote resource?

I've never used this library so I must be missing something, but the need for this case comes up from time to time in the applications I work on, e.g. show some data but also notify the user with a "soft loading"/"syncing" state.

Any suggestion on how this could be approached with remote-data-ts?

[OliverJAsh]

I also need this!

There's some discussion around this idea here: krisajenkins/remotedata#9

[raveclassic]

Hi, sorry for being sooo long with the answer.

At the moment we're not bundling "refreshing" state into the data model because "refreshing" is not needed as a separate state for the data graph and dependant computations in it. It's only needed for UI to still show some stale content while actual data is being reset by the user intent. So we're just keeping old state of RemoteData (either error or the data) in UI (React component state in our case) and implement exactly the same pairing approach that is described in this comment.

Things get even worse if (when) we need to distinguish between failures - is it a first-load failure or a refetch failure? Should we show previously fetched data if refetch failed and we need to show the error as well? How to define such state then? All this questions led us to one simple answer - keep UI things in UI and don't pollute data model.

[baetheus]

I hope @raveclassic doesn't mind, but this exact issue was why I ended up building @nll/datum. The primary difference between the two libraries is that Datum encapsulates only the concepts of temporal data state, ie: initial, pending, refresh, and replete(a term meaning the same thing as complete because I like even line lengths). Then we use the Either Monad Transformer from fp-ts to encapsulate error conditions and build DatumEither, as Either is imo the ideal abstraction for error handling.

Since I primarily use DatumEither in UI work it was much more important for me to encapsulate temporal states including refresh along with error states, especially when sequencing over multiple backend calls.

If there is any issue with me advocating @nll/datum here please let me know!

[grossbart]

I created a PR for this functionality (#57), maybe that could be a viable approach. If it isn't I'd be happy for feedback on a) the approach, and b) how else to publish this 😄 I've been using this in our app and it worked well so far.