Replies: 2 comments 1 reply
-
Remember, cancellation is a client-side thing. Once the request is made, your server will still get the request even if it's cancelled on the client. So the server should still process the deletion. Basically the browser simply stops listening for the response. With that being said, I'm not sure if Remix will still revalidate after a cancelled mutation, so you may not be able to confirm the deletion was successful. |
Beta Was this translation helpful? Give feedback.
1 reply
-
Maybe you could return null from the deleted component, so the component is still mounted, but the UI is not rendered. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I have a situation where I have an infinite list component which renders rows using absolute positioning. Each row has its own
useFetcher
which enables deletion of that row, similar to the example Ryan uses here. I'm trying to implement optimistic deletion of each row item by leveraginguseFetchers
in the infinite list component, and then manually filtering the deleted items from the list. This causes the component containing theuseFetcher
to unmount, which causes the deletion to be cancelled.So the gist of the problem is:
Optimistically deleting a list item which causes that component to unmount, cancels the deletion.
Possible solutions:
Visually hide the deleted row, instead of removing it from the DOM.
This is the technique Ryan uses in his video. But it's not as viable in a situation like this where the position of other items is determined in JS land. I can visually hide the row, but the other elements also need their position to be changed.
Raise the
useFetcher
to a parent component that doesn't unmountI don't think this is compatible with being able to do multiple mutations in parallel (say, if the connection speed was very slow).
Track which elements are optimistically deleted in JS and reposition items assuming they are marked for deletion.
This is possible, but it complicates my code quite a bit and makes it difficult to handle mount / unmount animations.
I think the ideal solution on my end would be able to turn off cancelling of the in flight
useFetcher
mutation for the list item that will be deleting. But I'm not sure how plausible that is based upon the implementation, which I'm assuming is tied the hook lifecycle. Any suggestions for how to handle this?Beta Was this translation helpful? Give feedback.
All reactions