feat(zero): Add support for StandardSchema to synced queries. #4870
Conversation
This was surprisingly difficult because StandardSchema supports
async validation. This meant that SyncedQuery needed to get forked
into ValidatedQuery, but fortunately that didn't spiral too far.
The other crazy unfortunate collision was that the async
validation means that `withValidation` becomes async. But the return
value `withValidation` is a query. And queries themselves are
promise-like. This means that when code that calls `withValidation`
uses await, it will unwrap recursively because that's what await does.
The result is that awaiting the result of `withValidation` in order to
return the query over the http response actually tries to run the
query.
The one lucky break was that `handleGetQueriesRequest` actually wants
{query: Q}, not Q as an input. So I was able to leverage that and
have `withValidation` return that shape not a raw query. This stops
the recursive unwrapping of promises from happening. I think the
previous API was actually better, but it's the best I could think
of.
We probably need to remove the ability to run queries directly, as
we've now added zero.run and friends. But we cannot do that until we
add tx.run. That will likely have usability impacts on reading data
inside transactions.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Bencher Report
|
| Branch | aa/standard-schema |
| Testbed | Linux |
Click to view all benchmark results
| Benchmark | File Size | Benchmark Result kilobytes (KB) (Result Δ%) | Upper Boundary kilobytes (KB) (Limit %) |
|---|---|---|---|
| zero-package.tgz | 📈 view plot 🚷 view threshold | 1,310.53 KB(+0.09%)Baseline: 1,309.32 KB | 1,335.50 KB (98.13%) |
| zero.js | 📈 view plot 🚷 view threshold | 209.95 KB(+0.04%)Baseline: 209.86 KB | 214.06 KB (98.08%) |
| zero.js.br | 📈 view plot 🚷 view threshold | 58.96 KB(+0.03%)Baseline: 58.94 KB | 60.12 KB (98.06%) |
|
nit: this is a breaking change. so Maybe complete the refactor so we do not need to do Related:
|
|
Yeah my plan is to complete the refactor first. |
|
turns out we must allow I forgot about this when adding all the new APIs. Before there wasn't any wrapping of the synced query so the user could create any function they wanted (sync or asnyc) on the backend to implement the synced query. |
I actually tried this (hopefully - i hadn't seen this link) but it didn't seem to work. The schema validators I tried always seemed to return a promise. |
This was surprisingly difficult because StandardSchema supports async validation. This meant that SyncedQuery needed to get forked into ValidatedQuery, but fortunately that didn't spiral too far.
The other crazy unfortunate collision was that the async validation means that
withValidationbecomes async. But the return valuewithValidationis a query. And queries themselves are promise-like. This means that when code that callswithValidationuses await, it will unwrap recursively because that's what await does.The result is that awaiting the result of
withValidationin order to return the query over the http response actually tries to run the query.The one lucky break was that
handleGetQueriesRequestactually wants {query: Q}, not Q as an input. So I was able to leverage that and havewithValidationreturn that shape not a raw query. This stops the recursive unwrapping of promises from happening. I think the previous API was actually better, but it's the best I could think of.We probably need to remove the ability to run queries directly, as we've now added zero.run and friends. But we cannot do that until we add tx.run. That will likely have usability impacts on reading data inside transactions.