Does bs-useFetch exist, do we need it, and what it should be like?

hoichi · 2019-12-09 20:33:19 UTC

Does something like useFetch exist in Reason (haven’t found it on redex)? And if not,

Do you think it’s needed?
How would you type its result? The most obvious is Pending | Data('d) | Error('e), but maybe a combination of Result and something else would be more composable? Or am I overthinking it?
(Also, how do you encode refetches? Your new request is pending but you already have some stale-ish data. Pending | Data('d) | Refetching ('d) | Error('e), maybe?)

yawaramin · 2019-12-09 20:43:14 UTC

I think https://github.com/bloodyowl/reason-react-update probably has a superset of useFetch's functionality.

arecvlohe · 2019-12-10 03:08:15 UTC

There are quite a few ideas out there already that might be good inspiration that I will link below. I think useFetch is a good idea, just like any other hook implementation that makes it easier for people to get started using reason-react without having to think about what promise/future implementation they want to use.

github.com

reazen/relude/blob/master/src/Relude_AsyncResult.re

/*
 AsyncResult is a specialization of AsyncData that uses a Belt.Result.t as the value type.

 This type also implements map/apply/flatMap/etc. to operate on the innermost a value (inside the Result.Ok)
 */
type t('a, 'e) = Relude_AsyncData.t(Belt.Result.t('a, 'e));

/**
 * Constructs an Init value
 */
let init: 'a 'e. t('a, 'e) = Relude_AsyncData.init;

/**
 * Constructs a Loading value
 */
let loading: 'a 'e. t('a, 'e) = Relude_AsyncData.loading;

/**
 * Constructs a Reloading(Ok(_)) value
 */

This file has been truncated. show original

github.com

reazen/relude/blob/master/src/Relude_AsyncData.re

/**
AsyncData represents the state of data that is being loaded asynchronously.

This type does not represent failures by default, but it can by using Belt.Result.t as your 'a type.

The reason for this is that not all async data loading mechanisms will necessarily fail.

The other interesting bit is that `Reloading` can be used if you already have data (e.g. an Ok or Error Result),
but you need to reload the data to get a new Result.
*/
type t('a) =
  | Init
  | Loading
  | Reloading('a)
  | Complete('a);

/**
 * Constructs an Init value
 */
let init: t('a) = Init;

This file has been truncated. show original

hoichi · 2019-12-10 10:54:52 UTC

Not sure what you mean. I guess useFetch can be implemented using useReducerWithMapState and, say, bs-fetch, but the package per se doesn’t have Fetch built in, and, anyway, the API feels much more involved than necessary. I think useFetch should be simpler to work with when it’s sufficient.

That said, I very much like the TEA-like approach of reason-react-update

Yes! Those types look just like what’s needed to me personally.

I guess we should also think about initial JSON parsing, but maybe JSON decoding is better done via Result.flatMap or something But then I’m a noob, so feel free to correct me, anyone.

Thank you both for the links!

arecvlohe · 2019-12-10 17:26:29 UTC

Decoding would be nice but I am unsure of how that would work. Only with something like decco, since it does codegen, could that be achieved but even then I am not sure. You will probably have to leave that up to the consumer.

hoichi · 2019-12-10 18:50:25 UTC

Sorry, I worded my previous reply badly. That’s exactly what I meant: expose Js.Json.t and let consumers handle the decoding.