Patterns for when server side state dictates UI and app behaviour

[bitttttten]

In my app, I have a few fields on the user object that come from the server that affect the UI of the app. This data can change a lot, so I was wondering what kind of practises or implementations people have done to accommodate this.

For my specific example, one field controls the status of the user's invite. Let's say it's called inviteStatus. I want to render some UI to manage an invite status if that value is pending. If the status is not pending, then I don't need to render this part of the UI.

For example:

//  GET /api/user 
{
    id: 1,
    inviteStatus: "pending" | "accepted" | "none",
}

This is no problem, I could do something like:

const { data, isLoading } = useQuery(() => fetch('/api/user'), ["user"])

if (!isLoading && data?.inviteStatus === "pending") {
    return <InviteStatus />
}

return null

So now here are my questions and concerns about this approach. If I update the user, I have to implicitly update the query cache of react-query. Either by invalidating it, or manually triggering it. Some complexity comes if I want optimistic UI updates.

// first update the query data for optimistic UI
queryClient.setQueryData(user, currentUser => ({ ...currentUser, inviteStatus: "none" }))

// update the api
await updateUser({ inviteStatus: "none" })

// now invalidate all the queries again to get the fresh value from the server
queryClient.invalidateQueries('user')

It seems quite involved, but not the end of the world. Is this an approach that's recommended? Or maybe I am missing a few things here and there.

[TkDodo]

I think your query component looks good. I'm not exactly sure about the optimistic ui update, it's best done with useMutation, but yeah, the chore is the same:

• in onMutate, do the optimistic update, which means calling setQueryData to update the inviteStatus of the current user
• request then happens with the mutateFn
• either refetch in onSettled, or update the user with the response in onSuccess, rollback in onError

the approaches are documented here and here