Expose mutation pending input for better optimistic updates

[nirtamir2]

Hi
I would like to suggest a feature I get from SolidStart - expose mutation pending input for better optimistic updates.
See https://start.solidjs.com/api/createRouteAction is the optimistic UI section.
In SolidStart you can get the mutation input for pending mutations.
This is useful in representing more granular optimistic updates, and it shines when we have more than a single query that is in flight. The user can get the pending input of the mutations and show them in the UI, and when the mutation request finish - the matching pending input is deleted.

You can see an example here https://github.com/solidjs/solid-start/blob/main/examples/todomvc/src/routes/index.tsx#L133

We can show the in-flight new to-do items easily.

  const [addingTodo, addTodo] = createServerMultiAction$(addTodoFn);
...
// Show the in-fight todos when adding them
 <For each={addingTodo}>
            {sub => (
              <li class="todo pending">
                <div class="view">
                  <label>{sub.input.get("title") as string}</label>
                  <button disabled class="destroy" />
                </div>
              </li>
            )}
          </For>

This approach moves the responsibility of optimistic-update UI to the UI itself, instead of the queryClient data layer. Which leads to a state that is easier to maintain and easier to debug.

If I would do it with @tanerstack/query, I would have to update the cache optimistically myself and handle success/error actions too. And for multi-action requests - this will be harder - because some of the mutations can succeed and some of them fail.

I think that useMutation can return some input property that equals the mutation input of the inflight mutation.
We can also expose inputs for all the in-flight request inputs for the same mutation.

We may need to expose useMultipleMutation / add an option to useMutation to mark if this pending input property will take the latest

Solid createRouteMultiAction returns a tuple of the mutation details and the mutation mutate function.

Suggestion API 1 (worse DX. but easier to migrate)

async function fn(param: FnParam){
 return [] as FnReturnType
}

const mutation = useMutation(fn)
mutation.input // returns FnParam 
mutation.inputs // returns Array<FnParam> 

Suggestion API 2 (better DX, harder to migrate)

async function fn(param: FnParam){
 return [] as FnReturnType
}

const [mutationDetails, mutateFn] = useMutation(fn)
mutationDetails.input // returns FnParam 
mutationDetails.error
mutationDetails.isPending  //etc...

and

const [mutations, mutateFn] = useMultiMutation(fn)

mutations.map(mutationDetails => {
 mutationDetails.input // returns FnParam 
 mutationDetails.error
 mutationDetails.isPending  //etc...

)

For example.

I'm not sure about the exact API I want (I think solid.js mutation API is better but it requires major breaking change) but I want to enable the option to get the mutation input in order to handle the optimistic updates in the UI instead of the queryClient.

WDYT?

[TkDodo]

I'm not against this, and it's not too hard to do, but I don't fully understand the value yet. This assumes that the query and mutation live in the same component, which imo is rarely the case. For example, the mutation can live in a dialog while the list that renders the query lives in a separate component.

So we would need a way to expose the input not only as a returned value from useMutation, but maybe also generally via another hook, similar to useIsMutating

[TkDodo]

and if you'd need a a separate hook, building something like useIsMutating should be possible on your end right now as well.

[nirtamir2]

Amazing! I will try it!

[TkDodo]

I noticed that variables get exposed but they are not reset when the mutation succeeds. We might ship this for v5 though, stay tuned. Thank you for putting the idea in my head 🙌

[TkDodo]

shipped it for v5 🎉

[nirtamir2]

Awsome!