Paced Mutations with Server-Side Updates
Hey again - just wanted to say thanks for the great library. Really impressive stuff in here, overall. In this case, I just want to make sure what I'm doing is actually unsupported by the library, so I'm doing it correctly.
I'm currently working on implementing server-side updates in my application, which also supports paced/debounced optimistic mutations. This combination seems to set up a bit of an issue when the user is editing a field that receives a server-side update.
To keep things simple, since server-side updates in my app are fairly rare, I'm planning on just reverting the user's optimistic changes by rolling back their optimistic pending transaction when a server update comes through that's for the same entity. However, it's not clear how I'd do this from the sync side. I don't see any clear way to get all the transactions for an entity in the collection, so there's not a great way to cancel all of them, particularly the ones that are only pending and have not yet been committed (the debounced paced mutations).
The transactions already persisting will presumably fail when they finish running (since I send an expected revision number that won't be correct on the server side), so I'm not too worried about those. But the paced mutations will stick around for 3 seconds before they persist and save-over the server-side updated data, which doesn't seem quite right. And since my custom debounce pacing also relies on the data being valid (invalid data just stays uncommitted), they could technically stay effectively desynced for even longer.
My current plan is to split off a new global JS map for each collection that simply holds the list of transactions that are currently affecting each item. I can then rollback all of these transactions if a server-side update for an item comes through. Does that make sense? It kinda feels like a second sync layer, to me? Is there any way of handling this within the sync layer or something like that?
I'm currently working on implementing server-side updates in my application, which also supports paced/debounced optimistic mutations. This combination seems to set up a bit of an issue when the user is editing a field that receives a server-side update.
To keep things simple, since server-side updates in my app are fairly rare, I'm planning on just reverting the user's optimistic changes by rolling back their optimistic pending transaction when a server update comes through that's for the same entity. However, it's not clear how I'd do this from the sync side. I don't see any clear way to get all the transactions for an entity in the collection, so there's not a great way to cancel all of them, particularly the ones that are only pending and have not yet been committed (the debounced paced mutations).
The transactions already persisting will presumably fail when they finish running (since I send an expected revision number that won't be correct on the server side), so I'm not too worried about those. But the paced mutations will stick around for 3 seconds before they persist and save-over the server-side updated data, which doesn't seem quite right. And since my custom debounce pacing also relies on the data being valid (invalid data just stays uncommitted), they could technically stay effectively desynced for even longer.
My current plan is to split off a new global JS map for each collection that simply holds the list of transactions that are currently affecting each item. I can then rollback all of these transactions if a server-side update for an item comes through. Does that make sense? It kinda feels like a second sync layer, to me? Is there any way of handling this within the sync layer or something like that?
