Deduplicate identical mutations

[Birkbjo]

Hello!

Is it possible to deduplicate identical mutations? Or a workaround? I saw that the mutationCache has a .remove() method, but I cannot really see this documented anywhere.

Context: We are creating a PWA with a form. The form can be edited offline, and the same cell can be changed after initial change. One request is typically sent after a field is blurred, so that change is stored on the server asap. Thus identical mutations will be created (and stored using PersistQueryClientProvider). Once the user goes online again, all these requests are sent. They are sent in order, so the data ends up being correct (unless user loses connection between mutations). However all the different values of the mutation is sent to the server, which is unnecessary when I'm just interested in the value/effect of the last mutation.

TLDR:
I would like only the last mutation to be stored in the cache. So if a new mutation with a key that is identical to one already in the cache, I want to replace that mutation with the new one.

Update:

I've managed to implement this, but maybe there's a better way?

    mutationCache.subscribe((event) => {
        if (event.type !== 'updated') {
            return
        }
        const { mutation } = event
        const duplicateMutation = mutationCache.find({
            mutationKey: mutation.options.mutationKey,
            // ensure previous mutation was fired before this
            predicate: (currMut) => currMut.mutationId < mutation.mutationId,
        })
        if (duplicateMutation) {
            mutationCache.remove(duplicateMutation)
        }
    })

[TkDodo]

You can define which mutations to persist, and there, you can decide to deduplicate mutations that you think are the same.
But I probably wouldn't worry about it too much. It seems like the multiple, identical mutations would also be sent if the user were online all the time? So why should that be different for offline mode?

[Birkbjo]

It seems like the multiple, identical mutations would also be sent if the user were online all the time? So why should that be different for offline mode?

This is a valid argument. But it would be unnecessary requests, especially if they've been offline for a long time.
Another usecase would be a toggle-request. What if the user is offline, and toggles a button (eg. completing a TODO). Then after a while (still offline), they incomplete the TODO again. It's unnecessary to send the complete- mutation, and could cause issues if connection drops between those requests (very unlikely, but theoretically possible?).

[TkDodo]

yeah that make sense, however, there is no easy way to detect if mutations are "the same". variables can change etc, and sometimes, it is okay to fire the same mutation twice. Like add a todo "go shopping" and then add another todo "go shopping". Why wouldn't that be valid if the user clicks "add" twice.

So what I would do is not store those duplicated mutations when persisting, but that wouldn't stop the duplicate requests being sent if the user keeps the app open & then goes online...

[Birkbjo]

Thanks for the swift answers!

however, there is no easy way to detect if mutations are "the same". variables can change etc

In my use-case this is not a problem, I can just check if some parts of the mutation is equal (some IDs and the value). If they are, I'm guaranteed that no mutation is needed.

So what I would do is not store those duplicated mutations when persisting, but that wouldn't stop the duplicate requests being sent if the user keeps the app open & then goes online...

This is probably fine, so will try to go that route.

[timabilov]

@TkDodo
Thanks for you detailed answer, and for such a wonderful library!
but, I have the same exact problem because my app can be offline even for multiple days.

I understand the problem of mutationFn serialization, but because of the default mutation function being with one common key has it own limitations

'update-todos' instead of ['update-todos, <todo-id>]

this kinda limits the way how we identify mutations for each item. We lose the ability to deduplicate multiple EDIT requests which are not idempotent. Even if mutation guarantees that proper sequence of events, still i think this is not correct behaviour in my case.
And again i see this as super realistic case, when someone can have hundreds of updates throughout the day.

It could update duplicate EDIT requests by our ID that we set(mutation Key or some other type of ID).
To clarify, this is only for paused mutations(offline mode)

[TkDodo]

isn't what I've written above already the answer to this question?

You can define which mutations to persist, and there, you can decide to deduplicate mutations that you think are the same.