You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 31, 2020. It is now read-only.
It's never needed by us (rendering a component means having requested some piece of data). We could re-define our own RemoteData type based on the original, by removing this case. The fold() method would have just 3 cases instead of 4.
An alternative could be to keep using the same method but export a utility function similar to fold
that combines NotAsked and Pending in the same case, effectively ignoring the "inexistent" NotAsked case.
do we want to treat all declared queries in the same way?
e.g. sometimes you want to render if the required data are there, and the re-render with additional data later.
This is already ok, since we have a per-query prop and we can combine multiple props
in render if e.g. two out of three are required: sequenceT(remoteData)(query1, query2 /* but not query3 */).fold()
Sometimes we want to render a success + loading state
(when we are re-fetching some data that we already have)
RemoteData doesn't handle this case out of the box.
What we might do: declareQueries defaults to the most common case (data | loading | success)
but one may configure it to get a fold() method comprising 4 cases instead of 3?
misc
{optional: other useful info}
The text was updated successfully, but these errors were encountered:
requirements
each "query prop" is currently exposed by
declareQueries
to the component as followshttps://github.com/buildo/react-avenger/blob/master/src/index.d.ts#L14-L25 which is roughly:
This is not the best to work with in common component scenarios, for various reasons among which:
if
/conditional
checks that can't be chained nor easily used to make a function exhaustivespecs (DRAFT with doubts)
RemoteData
https://github.com/devex-web-frontend/remote-data-ts exposes an ADT made of the possible cases:NotAsked | Pending | Failure | Success
Re
NotAsked
It's never needed by us (rendering a component means having requested some piece of data). We could re-define our own
RemoteData
type based on the original, by removing this case. Thefold()
method would have just 3 cases instead of 4.An alternative could be to keep using the same method but export a utility function similar to
fold
that combines
NotAsked
andPending
in the same case, effectively ignoring the "inexistent"NotAsked
case.do we want to treat all declared queries in the same way?
e.g. sometimes you want to render if the required data are there, and the re-render with additional data later.
This is already ok, since we have a per-query prop and we can combine multiple props
in render if e.g. two out of three are required:
sequenceT(remoteData)(query1, query2 /* but not query3 */).fold()
Sometimes we want to render a success + loading state
(when we are re-fetching some data that we already have)
RemoteData doesn't handle this case out of the box.
What we might do: declareQueries defaults to the most common case (data | loading | success)
but one may configure it to get a
fold()
method comprising 4 cases instead of 3?misc
{optional: other useful info}
The text was updated successfully, but these errors were encountered: