How to make optimistic updates while creation is still in progress

[priomsrb]

Related stackoverflow post: https://stackoverflow.com/questions/53180817/apollo-client-making-optimistic-updates-while-creation-is-still-in-progress

I want to be able to do updates on an object while it is still being created.

For example: Say I have a to-do list where I can add items with names. I also want to be able to edit names of items.

Now say a user with a slow connection creates an item. In that case I fire off a create item mutation and optimistically update my UI. That works great. So far no problem.

Now let's say the create item mutation is taking a bit of time due to a slow network. In that time, the user decides to edit the name of the item they just created. For an ideal experience:

1. The UI should immediately update with the new name
2. The new name should eventually be persisted in the server

I can achieve #2 by waiting for the create mutation to finish (so that I can get the item ID), then making an update name mutation. But that means parts of my UI will remain unchanged until the create item mutation returns and the optimistic response of the update name mutation kicks in. This means #1 won't be achieved.

So I'm wondering how can I achieve both #1 and #2 using Apollo client.

Note: I don't want to add spinners or disable editing. I want the app to feel responsive even with a slow connection.

[joe-re]

@priomsrb probably you can use update functions for that
https://www.apollographql.com/docs/react/essentials/mutations.html#update

[priomsrb]

@joe-re Thanks for the link. I had a look at the update function, but I'm not sure if it will help in this scenario. Here's my thinking why:

1. User creates a todo item
2. The create item mutation's update() function gets called with optimistic changes. Now let's say the server will take a long time to respond.
3. In the mean time, the user edits the todo item
4. The create item mutation hasn't returned from the server yet. So we don't know what ID of the todo item to update. So we wait until the creation is complete. In this time the UI is out of sync
5. The create item mutation's response from the server is received. update() gets called on the create item mutation.

In step 4, there's no update() function for us to utilize. So the UI goes out of sync.

Let me know if I missed something or there's a different way to solve this problem.

Thanks.

[jonmifsud]

Hi @priomsrb, I'm assuming you've fixed this but in case someone else may be reading; what we generally do is we set the id via a generated uuid beforehand - then updates would work on the same ID.

[priomsrb]

Thanks for your response. Yup I ended up going with that approach as well. My solution was: 1. Generate a UUID for the object on the client. This ensures that 2 clients cannot accidentally create 2 objects with the same ID. 2. Then the client behaves as if the item already exists. And instead of separate create and update mutations we have a single upsert (UPdate or inSERT) mutation. 3. The server then receives the upsert mutation and either updates the object if it already exists, or inserts it into the database

[frederikhors]

@priomsrb you can close this.

[bitofbreeze]

@priomsrb I'm worried about allowing the client to specify the id. I guess with uuid you're not likely to get collisions but what if someone intentionally forces collisions querying the endpoint directly? I guess your resolver could account for that. Are there any other potential shortcomings with allowing the user to specify an id?

[priomsrb]

@CSFlorin I can't actually think of any shortcomings with someone intentionally forcing a collision. Because this is an "upsert" operation, by forcing a collision, you are effectively just making a regular update operation. As long as your update operation does proper permission checking etc, there shouldn't be any issues.

One potential shortcoming of letting clients decide IDs is that if it gets displayed somewhere, they may try to get "creative" with how they name it. For example if youtube video IDs could be decided by clients they could put offensive words in the URL. Though you could argue that you can run the URL through some "safe language filter" that you would run on the video title anyway.