Update useUpdate to use react-query

[fzaninotto]

• [BC Break] update useUpdate signature
• pessimistic mode
• optimistic mode
• undoable mode
• hook time and calltime parameters and options
• Add unit tests
• [BC Break] Update useEditController to use it
• [BC Break] Removed deprecated <Edit successMessage> prop
• [BC Break] Update onSuccess and onFailure callbacks props and signature for <Edit> and <SaveButton>
• Fix tests
• Add upgrade instructions
• Update demos
• Update documentation

It turns out react-query's handling of cache, invalidation and stale queries is completely backwards in comparison with http logic, so this was not a piece of cake. I'm not sure we end up with less code to maintain than with our current Redux implementation.

import { useUpdate } from 'react-admin';

const IncreaseLikeButton = ({ record }) => {
    const diff = { likes: record.likes + 1 };
    const [update, { isLoading, error }] = useUpdate();
    const handleClick = () => {
        update('likes', { id: record.id, data: diff, previousData: record })
    }
    if (error) { return <p>ERROR</p>; }
    return <button disabled={isLoading} onClick={handleClick}>Like</div>;
};

[fzaninotto]

I had to disable application cache because it's incompatible with react-query. React-query gives an equivalent, albeit not controlled by the server. It's a BC break we should accept IMO, as application cache is a minor feature not widely used.

[fzaninotto]

I'm not happy with this one but I didn't find any better solution

[fzaninotto]

It's the job of the onMutate callback to set the context normally, but I actually need to define it beforehand (in the mutate wrapper), so I'm using this closure.

[fzaninotto]

The react-query doc advises to do this in onMutate, but in that case it's impossible to fire the success side effects right away. I had to use a wrapper for mutateAsync (and therefore mutate) instead.

Besides, the wrapper was necessary for the undoable mode, which shouldn't call the mutate callback until the action is confirmed.

[fzaninotto]

And we're Ready For Review!

[djhi]

Awesome work

[djhi]

If I understand correctly, we don't merge the declaration time options with the calltime ones?

[fzaninotto]

this is done by the mutation callback (the first argument of useMutation)

[djhi]

We ignore the declaration time options?

[fzaninotto]

No, they're taken care of by the useMutation callback

[djhi]

How can we be sure this event was dispatched for this specific query? What if there are multiple queries sent in a short timeframe?

[fzaninotto]

We can't. That's the way it'as always worked.

But it's not a real problem as, in order to perform a new mutation, users have to click somewhere, which dismisses the MUI Notification and commits the initial update.

[djhi]

Ok. That's only true for our implementation of the ui though