Extend `loading` indicator
mikhin opened this issue · 1 comments
Could we extend loading
from boolean
to enum maybe? For now, I miss, for example, some initial state, when the request has not yet been made. In current version for this case we have loading: true
, but this is not consistent with reality.
So the loading: true
issue is real. It will be fixed so that the default state of a store is loading: false
, and loading
key will always be tied to the actual fetcher function execution state.
After giving it a long thought I decided against adding state
/status
key to the store. The reason is rather simple: it will either mimic all the combinations of possible states, but as a string, or it will lack some of states.
The example that really gave me an understanding of why I don't want this is the following:
- store is initialized. Its state is
idle
- we start the loading. Its state is
loading
- fetch ends. Its state is
done
(orerror
if function throws)
But then we have a refetch strategy, right? Say, by interval.
- we start the fetching again, but there is cached data already! Is it
loading
? If so, why do we need it at all if all it does is just a replication ofloading
flag? So let's assume it iscachedDataAndLoading
or whatever - but this fetch ends with an error. Again, it shouldn't be just
error
, it should becachedDataAndError
There's a reasonable chance I'll introduce something like loadingSlow
for cases where fetching lasts longer than a certain timeout. So all loading flags will double.
So in one case we have a replication of 3 boolean checks, in other—a lot of strings (imo, rather cryptic as well), that, on top of it all, can be created in userland rather easily if one needs it very much.
In the end it seems that it would be better to have a thorough documentation on what each store value means and when it can have certain values. The combinatorics of loading
, error
and data
are not that scary, I would say 😄