`ConvexClient` questions
I was happy to see
ConvexClient released and I recently swapped it into a couple of lightweight integrations I'd previously done with Preact Signals and Lit Reactive Controllers, replacing a similar "generic" reactive client I'd built myself on top of BaseConvexClient. ConvexClient ended up being more or less a drop-in replacement, which was great!
Having tried it out, I do have a couple of observations / questions; they aren't really support things, per se, but this forum channel seemed like a good spot to raise them.
1. My own client had support for optimistic updates, patterned after (and borrowing types from) the React client. I see that ConvexClient doesn't have optimistic-update support; I can imagine a few reasons why that might be and am curious to know what the actual one(s) are.
2. FYI, when I was doing my Preact Signals integration, I ended up adding a configuration option to my reactive client allowing the equivalent of ConvexClient's _transition() method (where callbacks are invoked) to be wrapped in a developer-provided function. This was so I could use Preact Signals' batch() function to optimize signal performance in the case where multiple Convex queries updated at once. I unfortunately no longer have the simple test cases I was using that led me to conclude this was necessary / desirable, but could probably reconstruct them.2 Replies
Hi @Gray, great to hear this useful! We thought about these things building ConvexClient and on both decided to go with the simpler approach to start, but know they're on our radar.
1. The reason is that we can imagine different optimistic update interfaces, so are thinking about exposing something lower-level that the current React client optimistic update model is build on top of. We haven't exposed something lower level yet in
BaseConvexClient yet, but it might look like synchronously exposing all in-flight mutations, allowing metadata to be attached to them, and registering for updates when these succeed or fail.
2. We thought about a batch option for this in ConvexClient and cut it for simplicity — but totally, it's helpful to hear this but you don't have to provide a repro because we have one with SolidJS.
The way this batch: option worked is you hand us a (callAllCallbacks) => { ... } like
which in this case reduces to batch: preact.batch
Right now the recommendation would be to stick with BaseConvexClient if you want this transition API, but helpful to hear this would be useful to you. @Gray what are you appreciating about the simpler client?Thanks, @ballingt! Makes sense. RE: optimisitic updates, I suspected the reason was something along those lines. RE: the transition API, glad (and not surprised) to know it's already on your radar.
Fortunately, in my current end-to-end use case, I don't think either of these features is critical. If that proves to be wrong, it should also be pretty easy for me to temporarily switch back to my own client under the hood.
My interest in the simpler client is due to the fact that I'm not using React, but wanted the same level of seamless reactivity at the application-code level. It wasn't super difficult to roll my own on top of
BaseConvexClient, but it was clear that there was a useful layer of abstraction missing prior to the release of ConvexClient.