`_creationTime` issue for `withOptimisticUpdate`, and thoughts
Say I have a
messages list to display and I need to show the _creationTime for each of the message
Once I have inserted a message and I want to show the message immediately instead of waiting for a api call.
1. withOptimisticUpdate is used on the api.messages.insert mutation, updating the api.messages.list query.
2. Inside withOptimisticUpdate, I have to set message._creationTime = clientSideNow(), and display the time.
3. Since the OptimisticLocalStore is fully clientSide and temporary, after the server have finished the real mutation, the newly inserted message will be updated to message._creationTime = serverSideNow().
4. If there is any network latency, the message list UI will experience an unexpected update because of the date change.
5. Same situation for message._id.
Workaround1: Add my custom message.localFirstCreationTime, which is generated and passed from client side.
Workaround2 as a feature request: allow overriding at least _creationTime?
5 Replies
When the mutation finishes, the optimistic update shouldn't continue to be applied, assuming you're using the optimistic update API on useMutation. Yes, the creation time will be set on the server. If you want to sort by client creation time, as you mentioned you can pass up a client timestamp, and do your sorting that way.
What is the issue you're having with the "unexpected update"? When the real data comes down, I'd expect an update. If you don't want certain cells to re-render, maybe adjust their props to be more predictable / stable across renders, e.g. the values they're displaying and their index?
The
unexpected update means that, not only we need to sort, but also need to display the _creationTime field. Before mutation finish, displays 11:58.40, after a short time when mutation finish, the _creationTime become 11:58:40. While the client side creationTime is stable. However as this is basically how optimistic update works, the ui should avoid accessing unpredictable fields.And does this cause an issue for users, or is it just an optimization where you'd like to reduce the number of renders? Or is the time changing confusing? I like to show optimistic content as grey or with a spinner to indicate it isn't "real" yet, but I know other UIs like to make it look the same right away.
Kind of thought that this feature is to make app work like a
local first one, to me it doesn't seem like cache.It can serve that purpose. For non-local-first apps, until it’s committed to the server, it’s somewhat ephemeral. If the user closes their browser thinking they sent a message, they’ll be disappointed. For local-first I’d personally want to commit it to a local store before suggesting to the user that it has been confirmed by the application.
Do you agree?