Setting `_id` when creating documents with optimistic update
We absolutely love optimistic updates and use them heavily on our app. There's however some places where we can't use them because we would require Convex to create a document with an id that we pass it which is equal to the id of the document created optimistically.
In our app, when you create a page, a document gets created and we navigate the user to
pages/<doc_id>
Doing this optimistically would break atm...16 Replies
Thanks for posting in <#1088161997662724167>.
Reminder: If you have a Convex Pro account, use the Convex Dashboard to file support tickets.
- Provide context: What are you trying to achieve, what is the end-user interaction, what are you seeing? (full error message, command output, etc.)
- Use search.convex.dev to search Docs, Stack, and Discord all at once.
- Additionally, you can post your questions in the Convex Community's <#1228095053885476985> channel to receive a response from AI.
- Avoid tagging staff unless specifically instructed.
Thank you!
we have similar issues when dragging a block into a grid, where users have to wait until the document is actually stored in convex and the grid to rebuilt to be able to edit (e.g. resize) the dropped block (otherwise they'd be editing a document with an id that doesn't exist in convex and is just an id we generated in the optimistic update). Given that we have a pretty complicated schema which leads to longer validation times this issue is very easy to replicate.
We'd love if Convex supported this, similar to how Firestore lets you create a document reference/id before actually writing the document
I ran into something similar yesterday. I insert a document with a mutation. But then I need to query that same document in order to have a reactive subscription
Optimistic is not meant to be used everywhere. But if you insist on doing that, you can create another type such as _myId and pages/<myId> instead, nothing is stopping you 🙂
The issue of editing a doc that still hasn’t been stored in convex persists though
Yeah I'd love client side ID generation too so you can do more powerful optimistic updates like this -- we just haven't had the time to build it yet.
The current workaround (which admittedly isn't great) is the suggestion above of creating your own
id field where you can control the ID generationthanks @sshader ! Is this something on your roadmap? just to be able to decide on how much effort is worth investing from our side on a workaround
Do you have any updates on this?
Having id generated on client side would also help with flash of content in React, that might sometimes happen when using the
_id as key attribute of dynamically generated components. Having a consistent key would help avoid remounting / rerendering.it's likely to be something we need to address with the local sync engine ( @sshader can correct me if I'm wrong), so we should have some progress here in the next month or two. we're starting to spin up effort on the local sync engine again this week
that is very nice news
Sorry for bringing this back, but is there a solution as of today? @Matt Luo @Jamie
Following up here as well! Is there a solution for client side Id generation, or optimistically updating two things at once, where the second depends on the ID of the first?
+1 to this feature! my use case: https://discord.com/channels/1019350475847499849/1410036885715161181
+1 to this feature, I am new to convex, but not being able set my own _id is seeming to cause the largest complexity add in migrating my from my existing setup (coming from firestore). both for reasons stated above, and for dealing with contextually relevant ids that mean something to a user (https://discord.com/channels/1019350475847499849/1414125762516353194/1414125762516353194)
this project is being actively developed by @Nicolas on our team right now
Hey all! I see this is relevant to my current questions, and ChatGPT doesn't know enough to answer it :P. Can someone who knows the engine better than I tell me if this is a solved issue, or is being solved?:
Using withOptimisticUpdate in rapid succession:
1. Add todo #1 w/ _id: 'temp:...'
2. Add todo #2 w/ _id: 'temp:...'
3. Add todo #2 w/ _id: 'temp:...'
Someone else also adds a todo in the middle of all those
It seems like the optimistic updater queues your optimisitc update, then when a query subscription snapshot comes through, it removes them, updates from the snapshot, then replays your remaining optimistic updates (says ChatGPT and my docs reading, but I half guessing here)
If a query subscription snapshot comes through from the other persons update in the middle of all that, wouldn't the optimistic updater think that snapshot includes my optimisitic item, therefore removing one of my optimisitc updates? Or is it smart enough to know that that snapshot (from the other person's mutation) doesn't include one of my items, therefore maintaining the optimistic queue as it should?
Any other information on how this works would also be helpful.
At the end of the day, I'm trying to create a cheap version of what you would get with more of this type of app approach:
Using something like redux and a local store of queued operations:
1. Add todo #1
2. Add todo #2
3. Add todo #3
It's more a local first approach, where your source of truth is kind of local, and you're syncingto the server, but you would of course need to reconcile other entries from the server into your redux state.
Now, I don't want to build a local first app if I don't have to, and I (don't think) convex isn't storing those and picking back up on mutating after a page refresh, but to get a snappy optimistic UI like that, where the server interactions are invisible is the goal, at least at first glance to the user.
Let me know if convex has any other tricks up its sleeve that addresses this need, or if I'm just not understanding how it works.
Also, would this optimistic update also carry over to any other instance of the same convex query hook mounted elsewhere in the app (similar to how react query would), or would this optimistic view be local to only the component the mutation was in?
Thank you!