Can exchanges debounce field mutations?

[arcanis]

I have a text editor with live saving, similar to Google Docs. The current model uses urql as unique data layer, so each keystroke triggers a mutation associated with an optimistic update. Of course, when writing large documents it wastes a lot of bandwidth, so I want to offset this by debouncing the http query to only submit data once the user stopped typing for N seconds.

On the other hand those entities have other fields, and some of them (for instance whether the document is public or private) have to be persisted immediately. So a blanket debounce would be problematic as well.

The way I see it I have two options:

• I could use an additional layer on top of urql (for example using Redux or similar) so that my components would publish and extract their updates to this intermediary layer rather than urql itself. This layer would then decide the logic to persist the changes through urql. I'm not a fan of this idea, because it involves adding yet another layer, with all the edge cases that come with it, and the urql API is quite elegant in itself - I'd like to keep the primary way of consuming data.

• Another option might be to use the urql exchange API to debounce the specific fields right before they reach the fetch exchange. However I'm not entirely sure how that would look like (functional isn't my forte, and wonka is very functional!). Is it even possible? It would involve splitting one request (1 immediate field update + 1 debounced field update) into potentially multiple (one for the immediate field, then later another for the debounced field), would that work with optimistic updates? Would urql manage to keep track of everything happening?

What would you recommend?

[kitten]

I don't think an additional layer makes much sense given that the state of modifications would have to be duplicated for such a simple case.

I'd opt for queueing up changes in local state and would just buffer or denounce them to combine them as needed or determine when it'd immediately have to be sent off as this would like be a small hook with a queue and a setTimeout attached to state changes.

It's totally possible to use an exchange too and I could cobble some code examples together here if you have some specific description of what needs to be sent ASAP vs denounced. But a wrapper around the mutation hook is likely much easier to achieve given that this sounds like a UI state Problem for a single mutation, right?

[arcanis]

The problem is that I have multiple components that need to access the same editors data (I have multiple editors!), and as they are all fairly isolated they may not even be in a single React branch. A single setState wouldn't be enough, I would need some proper way to share a global state - and the urql layer was a nice way to achieve that, will all components registering to the same entity and thus immediately receiving all the updates thanks to the optimistic update.

That being said it also had a significant drawback in that I had to serialize the editor data states to JSON (and back) at each keystroke (I use draft-js, which uses immutable.js, whose data structures are complex and have to be transformed to json before being sent to urql), so it wasn't perfect either. Perhaps using a state (either local or global) would solve both problems at once, offsetting the complexity cost. I'll investigate.

Out of curiosity, I'd still interested to see the code you mention - I've updated the following playgrounds (Server | Client) to represent todo objects with both title and body, plus another private field. Could an exchange allow the updates to private to flow immediately, but debounce the updates to title and body (without breaking their optimistic updates, otherwise React will revert the input content)?

[arcanis]

Field mutations would be a bit awkward to implement, but without this requirement the following should be a working debounce exchange, which was perhaps the main thing I wasn't sure how to implement. Thanks for your help!