Handling stale data & optimistic updates.

[akselander]

Hey! We added boxed wrappers to our graphql queries to reduce amount of states that we need to handle.
Initially we started with AsyncData<Result<Data, Error>>

const [queryState, refetch] = _useQuery({
  query,
  variables,
  context: React.useMemo(() => context, contextDependencies),
  pause,
});

let state: AsyncData<Result<Data, Error> = AsyncData.NotAsked();

if (queryState.data) {
  state = AsyncData.Done(Result.Ok(queryState.data));
}

if (queryState.error) {
  state = AsyncData.Done(Result.Error(queryState.error));
}

if (queryState.fetching) {
  state = AsyncData.Loading();
}

return [state, refetch];

Unfortunately that made it hard for us to add optimistic updates. So instead we moved to AsyncData<OperationResult> and added a mapper toResult in case we want to modify that data.

const [queryState, refetch] = useQuery({
  query,
  variables,
  context: React.useMemo(() => context, contextDependencies),
  pause,
});

let state: AsyncData<UseQueryState<Data, Variables>> = AsyncData.NotAsked();

if (queryState.data) {
  state = AsyncData.Done(queryState);
}

if (queryState.fetching) {
  state = AsyncData.Loading();
}

return [state, refetch];

This however feels a bit like a step back - we are handling idle and fetching slightly better, but then we need to unwrap everything anyway. Do you guys have any suggestions on how to handle data fetching with more complex life times?

[bloodyowl]

hi!

what exactly do you mean by optimistic updates? those should not trigger a loading state on a query.

can you provide an example of the issue?

[akselander]

@bloodyowl hey, sure thing, let me describe the problem better. LMK if this makes more sense, maybe there's a pattern I don't know yet that would solve my issue.

Let's say we create a way to read an async list of todos.

let todos = AsyncData.Idle()

async function fetchTodos() {
    todos = AsyncData.Loading()
    response = await fetch(...)
    todos = AsyncData.Done(response)
}

Then let's say we want to be able to add the todo.

let action = AsyncData.Idle()
async function removeTodo(id) {
    action = AsyncData.Loading()
    actionResult = await fetch(...)
    action = AsyncData.Done(actionResult)
}

We could then use todos to display the initial list, and use action to display the action state. Let's consider two additional cases:

• optimistic updates on our UI
• refreshing stale data while showing it in the UI

Both of these are not possible with a singular AsyncData, since Loading cannot carry any data with it. If it could we could try something like these:

optimistic updates:

let action = AsyncData.Idle()
async function removeTodo(id) {
    action = AsyncData.Loading(id)
    actionResult = await fetch(...)
    action = AsyncData.Done(actionResult)
}

if (action.isLoading() && action.getLoading() == todo.id) {
 // show action dots
}

stale data refetches:

async function fetchTodos() {
    if (todos.isDone()) {
      todos = AsyncData.Loading(todos.get())
    } else {
      todos = AsyncData.Loading()
    }
    response = await fetch(...)
    todos = AsyncData.Done(response)
}

todos.match({
  Loading: (stale) => // display stale UI,
})

[bloodyowl]

yeah, generally having two distinct AsyncData is what I'd recommend, it's a pretty powerful pattern since it lets you compare the data.

Let's imagine we have:

type Item = { id: string };
declare const data: AsyncData<Result<Item[], Error>>;
declare const nextData: AsyncData<Result<Item[], Error>>;

where data is the main query, and nextData represent subsequent queries after the initial load, or data received from a mutation.

in this case, we can declaratively differentiate between all the cases:

data.match({
  NotAsked: () => null,
  Loading: () => <FullPageLoader />, // initial load, main data being loaded
  Done: (result) => 
    result.match({
       Ok: data => {
         const previouslyLoadedElements = new Set(data.map(item => item.id))
         // let's say we want to highlight the newly fetched items,
         // we can now easily diff between the "stale" data and the more recent one
         const newlyAddedIds = nextData
           .mapOk(data => Array.filterMap(data, item => !previouslyLoadedElements.has(item.id) ? Option.Some(item.id) : Option.None()))
           .toOption()
           .flatMap(result => result.toOption())
         return (
           <>
             <DataView
               data={data}
               newlyAddedIds={newlyAddedIds}
             />
             {nextData.isLoading() && <SmallLoader />
           </>
         )
       },
       Error: error => <ErrorView error={error} />
    })
})

you have various possible applications of the pattern, pagination (have data be the aggregate and nextData the last page), stale data (have nextData represent the refresh while keeping data) …

for optimistic updates particularly, I'm not sure the pattern really has to do with AsyncData though.

[akselander]

This pattern does seem fairly powerful.

For simplicity sake, let's say that you can't trigger the action when our data is not ready.
Here's how I see a flow for async data that can be updated with optimistic update:

fetchData/actionData	IDLE	LOADING	DONE
IDLE	blank	invalid	invalid
LOADING	loading	invalid	keep optimistic update
DONE	real data	optimistic update	real data

both fetchData.DONE && actionData.LOADING and fetchData.LOADING && actionData.DONE, seem bit hard to replicate. Should it look something like this? Or would it be better to update fetchData as a side effect?

const fetchData = ...
const [actionData, optimisticValue] = ...

if(actionData.isLoading()) {
  return optimisticValue
}

if(actionData.isDone()) {
  return actionData
}

return fetchData

[bloodyowl]

yeah, you can do something like this:

const query = ...
const [mutation, optimisticValue] = ...

return {
  data: query.mapOk(data => {
    return match({query, mutation, optimisticValue})
      .with({ mutation: AsyncData.P.Loading, optimisticValue: P.select(P.not(P.nullish)))}, optimisticValue => {
        return optimisticValue
      })
      .with({ mutation: AsyncData.P.Done(Result.P.Ok(P.select()))}, dataFromMutation => dataFromMutation)
      .otherwise(() => data)
  }),
  // just to indicate that the mutation is currently running
  isLoading: mutation.isLoading(),
}