Different optimisticResponse and update is called multiple times

carvajalconsultants / apollo-link-offline

An Apollo Link to queue mutations when offline or network errors exist.

MIT License

71 stars 15 forks source link

Different optimisticResponse and update is called multiple times #13

Closed sajadghawami closed 2 years ago

sajadghawami commented 2 years ago

Hey there,

very nice library!

Unfortunately, i ve seen these two bugs:

You need to set optimisticResponse if you want to use the update in an apollo mutation. So you end up needing to set your own optimisticResponse besides the one that this library will provide. Otherwise the update will not shoot. So you end up having two different responses.
Apart from having two different optimisticResponse, update function in a mutation will also be called twice for each optimisticResponse. You'll end up having update called 4 times.

Thank you.

stevewillard commented 2 years ago

@sajadghawami did you happen to find a workaround to this behavior? I'm seeing it as well.

sajadghawami commented 2 years ago

@stevewillard

When i dug deeper, i found out that there was a pretty big bug. Since this repository is not maintained anymore i ended up copying everything over, fixing it and optimizing it for my application.

Feel free to message me if you need the code i ended up with.

Cheers.

stevewillard commented 2 years ago

@sajadghawami Totally - that would be super helpful if you could share your modified version! Thanks.

miguelocarvajal commented 2 years ago

Hey guys! Sorry I've been a bit out of the loop. Had some personal issues to attend.

@sajadghawami If you have the code, I can include it in the main repo.

sajadghawami commented 2 years ago

@miguelocarvajal

no worries, hope you are doing well! thank you for your great work! :)

I created this gist.

Please keep in mind that it is a little tailored to our application (see CUSTOMER_HYDRATE)

Everything works fine, but sometimes the app would successfully send all the mutations to the server and update the apollo-cache accordingly, except for the last mutation. The mutation would go successfully through to our server, but somehow the app would swallow the last response.

It was a really long and messy fight with the apollo-cache, different versions of the apollo-client that wouldn't act as promised so i ended up hydrating the data at the end, to always keep the UI in sync after all mutations where successful.

We are using this in production and didn't have any problems yet. If you happen to have a more elegant solution to our little desync problem, i would be very glad if you could share it :).