Status indicator

I think the result should have a field indicating the status of the query. It could be a simple boolean flag loading or a more sophisticated status enum (to indicate revalidation, etc.).

Checking data for truthiness does not cut it if you consider that the data returned from the fetcher could in theory be null (or even undefined).

[shuding]

Thanks for sharing @darrenjennings! I’ll also add my 2 cents.

I love the idea, but enum is a bit annoying to me. What do you think about this proposal:

const { data, error, state } = useSWR(...)

state.pending // => true
state.success // => false
state.error // => false

The good thing is that users don’t need to import all the enums, and the editor will autocomplete.

---

The only concern for this status indicator idea is, since we are building these “high-level” states, their names have to be very clear and have to be complete.

Complete means that we have a group of 3 base values (data, error, isValidating) and all of them have 2 states, the derived states will be 2^3 = 8 different possibilities. It grows exponentially:

• (data = 0, error = 0, isValidating = 0): idle
• (data = 0, error = 0, isValidating = 1): pending
• (data = 1, error = 0, isValidating = 0): success
• (data = 0, error = 1, isValidating = 0): error
• (data = 0, error = 1, isValidating = 1): retrying
• (data = 1, error = 0, isValidating = 1): revalidating
• (data = 1, error = 1, isValidating = 0): error_stale
• (data = 1, error = 1, isValidating = 1): retrying_stale

These are a lot and I believe there is at least one use case for each state. So I preferred to leave it to the users to determine which states their app needs. But after all I can see the benefit of directly returning the ready-to-use app state to the user.

[darrenjennings]

@shuding I like the naming of all 8 states! Even though it seems like it could grow exponentially, it does limit the guesswork on how many states your swr-dependent ui can devolve into*. Though we had some discussion here around the ambiguity of the state names e.g. “what is ‘error’?”. I think it can mostly be explained to say a swr state error is “fetcher threw”. If you don’t want to throw (e.g. 404 == user is logged out), then you can catch in your fetcher.

I love the idea, but enum is a bit annoying to me. The good thing is that users don’t need to import all the enums, and the editor will autocomplete.

It would be my preference to define them as string literals so that you can do simple equality checks that can be used with useReducer or switch statements without having to check multiple state.* flags. This gives you editor autocomplete as well. It is more of a state machine way to do it.

type swrState =
| 'idle'
| 'pending'
| 'success'
| 'error'
| 'retrying'
| 'revalidating'
| 'error_stale'
| 'retrying_stale'

* and maybe it is overblown to think there is another property that would be introduced, maybe cancelled? I never cancel requests so open to if you think there would be a new state that would give it 16 states.