In what states mutation can be?

[RIP21]

Hey, I wrote a small abstraction over useQuery and useMutation and I'm wondering about one thing.
Can mutation result be in a stale state?
I guess it may have only errors (error state), data (done state), or have both, so then it's in partial state and extensions (no matter the state). But what about stale or stale-partial I think those are impossible?
Note that I'm talking ONLY about the response from mutate({ ...someArgs }).then(response => {} ) <== this response. Not the one that we're getting from [response, mutate] = useMutate() as this one indeed may have stale state on 2nd call of mutate.

If you're wondering what abstraction I've done, I wrapped useQuery and useMutation so it returns a number of union types like

export type UrqlStates<Data> =
  | FetchingState
  | DoneState<Data>
  | ErrorState
  | IdleState
  | StaleState<Data>
  | PartialState<Data>
  | PartialStaleState<Data>

export type FetchingState = {
  state: 'fetching'
}

export type DoneState<Data> = {
  state: 'done'
  data: Data
  stale: false
}

export type StaleState<Data> = {
  state: 'stale'
  data: Data
  stale: true
}

export type IdleState = {
  state: 'idle'
}

export type ErrorState = {
  state: 'error'
  error: CombinedError
}

export type PartialState<Data> = { state: 'partial'; error: CombinedError; data: Data }

export type PartialStaleState<Data> = {
  state: 'partial-stale'
  error: CombinedError
  data: Data
  stale: true
}

So then I can branch on it using state field type-guarding avoiding excess ? also making sure no case is got forgotten like that.

  const [responseMachine] = useEnchanceQuery(useSomeCodegeneratedQuery())
  switch (responseMachine.state) {
    case 'idle':
    case 'fetching':
    case 'stale':
      return <GenericSpinner />
    case 'partial':
    case 'partial-stale':
    case 'error':
      return <GenericError />
    case 'done': {
       return <SomeUi data={responseMachine.data} /> // here data us non-nullable
    }
    default:
       return impossibleState(responseMachine)

Just want to limit the number of cases to avoid having some useless one here in switch :)

Same for mutate.then(response => {...}) so I can branch inside the then callback on response.state field the same way :)

[kitten]

Hiya 👋

Mutations cannot carry a stale flag. The stale flag signfies that urql is expecting another result for a query. Hence this flag only currently applies to queries. The important point here is that it's implemented currently by both @urql/core and the cache exchanges. Whenever we know that a new network result will come in for queries we can set this flag.

This stands in contrast with mutations. Mutations are often "fire and forget" and can be executed multiple times, each resulting in a new independent result.

You can see this guarantee in action here too: https://github.com/FormidableLabs/urql/blob/e5ea77e836b11be379327bee7abe74109d0adabc/packages/core/src/client.ts#L244-L251

Basically what you should keep in mind is that an algebraic data-like state isn't best suited to deal with query results; in essence all fields on an OperationResult are mutually exclusively conveying different information, so you have an exponential number of states and many use-cases will want to check for different ones.
stale may still have a result or error, fetching may still give you the last piece of data that the hook had on hand, idle doesn't really exist, etc, etc.

[RIP21]

Great! I will remove them then! :)
BTW, what do you think about all the possible states that I mentioned above, but for the query, am I missing anything? :)
Just to reiterate they're idle, fetching, done, error, partial, stale, partial-stale.

[kitten]

Reason Urql does something similar however, as I said, it's an exponential problem 😅 https://github.com/FormidableLabs/reason-urql/blob/e0eaf960f9852fa3f0e068a8feee3be460831d40/src/Types.res#L143-L150

So you'd have to enhance almost all of these with stale also taking into account that stale and partial can be subtly different things and coincide to hint at a different state too. So basically, what I'm saying is, a list of algebraic states may actually be more unwieldy in many cases unfortunately.

[RIP21]

Anyway :D So far list of those works good, so let's pray for good :D My use cases are pretty simple and they'll continue to be so, so I guess I'll risk it :)
Glad you have a similar approach :P I like to call it shitty state machines :D Not sure how it's in Reason, but in TS it's :D