You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a live updating profile view. Whenever there's a change in one of the profile's TextFields, I mutate the local data immediately and send a request to update their profile and re-validate:
Note: The /api/account endpoint already returns the updated user profile (after server-side validation), so we don't really "re-validate" at all. This is the pattern described in this issue and the documentation.
Because that last mutate call occurs far after the user made the change, it "re-types" what happened (this is expected, but not ideal):
Expected Behavior
How did you expect SWR to behave here?
SWR should batch together re-validation requests that contain promises (much like how React batches together DOM/state updates).
Mutate calls that are not promises should be immediate:
Mutate calls that have promises should be batched together (i.e. when a new Promise comes along, cancel/ignore all the previous ones (that are still pending) and mutate based only on the resolution of that most recent Promise):
SWR version. ^0.2.2
Add any other context about the problem here.
My current solution is to just update the data locally, perform the PUT request to update the database record, and then re-validate once all of the requests have gone through and there hasn't been another change within 500ms:
consttimeoutId=React.useRef<ReturnType<typeofsetTimeout>>();if(timeoutId.current)clearTimeout(timeoutId.current);awaitmutate('/api/account',newUser.toJSON(),false);if(!newUser.id){console.warn('[WARNING] Cannot update user without ID.');}else{consturl=`/api/users/${newUser.id}`;awaitaxios.put<UserJSON>(url,newUser.toJSON());timeoutId.current=setTimeout(()=>mutate('/api/account'),500);}
That behavior, while not ideal, looks like this:
The text was updated successfully, but these errors were encountered:
Bug report
Description / Observed Behavior
What kind of issues did you encounter with SWR?
I have a live updating profile view. Whenever there's a change in one of the profile's
TextField
s, I mutate the local data immediately and send a request to update their profile and re-validate:Note: The
/api/account
endpoint already returns the updated user profile (after server-side validation), so we don't really "re-validate" at all. This is the pattern described in this issue and the documentation.Because that last mutate call occurs far after the user made the change, it "re-types" what happened (this is expected, but not ideal):
Expected Behavior
How did you expect SWR to behave here?
SWR should batch together re-validation requests that contain promises (much like how React batches together DOM/state updates).
Mutate calls that are not promises should be immediate:
Mutate calls that have promises should be batched together (i.e. when a new
Promise
comes along, cancel/ignore all the previous ones (that are still pending) and mutate based only on the resolution of that most recentPromise
):Additional Context
SWR version.
^0.2.2
Add any other context about the problem here.
My current solution is to just update the data locally, perform the
PUT
request to update the database record, and then re-validate once all of the requests have gone through and there hasn't been another change within 500ms:That behavior, while not ideal, looks like this:
The text was updated successfully, but these errors were encountered: