Rename resolve[d]
to resolve[d]Mock
#160
Comments
I think it's okay to be "forced" to manually query the data in a way that complies with the schema's zod (if expanded references could be parsed as well). Query results are iffy to work with until they've been parsed and you can be sure of the shape. Ideally i'd like a way to parse a document with expanded references so you can query a full expanded document in one go. Maybe a Then you'd have:
|
At this point, I think the normal inferred types and the parsed types are enough. I think the breaking change I need to make is renaming |
resolve[d]
to resolve[d]Mock
My workaround for this so far, and you're probably not gonna like this, is to use |
Yeah… I still believe the best solution for this should be to try and type groqs directly. The reality is that ‘ + = ’ is the only real truth. Resolution is just a common operation in groq, but by no means the only that should be handled. Parsing should only exist to be smart enough to know that, whenever we retrieve that specific field, we want to change its type, ie a datetime field should always produce a ‘Date’. I think there’s a reality where ‘defineType’ gives enough hints to derive the basic types, where this library no longer needs to do that. If that’s true, it becomes a matter of giving some kind of ‘sanity-typed-groq-builder’ those types and let it drive the correct types from that. |
As @mckelveygreg made clear in #158, some things about "resolve" are unclear:
s.resolved<...>
should be the type but with references resolved. Right now it's both parsed AND resolved. These should be two separate types.docType.resolve(mock)
doesn't describe that it's for mocks, so it implies it does something you'd want in application code, which is untrue.docType.resolve
anddocType.parse
should be independent. Resolving also parses, which is unexpected. We should be able to do both to the same doc, but it's unclear how this API should go.This was a consequence of the main use case I made this library for, which is not everyone's use case:
However we go about fixing this, there's definitely breaking changes (which is fine). I think making
s.resolved<...>
the same ass.infer<...>
, except references are the type of the resolved document should be easy.The bigger issue is parsing. Parsing expects the value of the doc, and it essentially needs to handle a doc that has expanded references as well (and return the correct types). Expanded references are only one thing that a query can do that's "non-standard", which starts opening the door into parsing any valid query. Doing the work for this specific use case will likely cover a lot of use cases, but ultimately end up opening the door into individually solving the various groq query use cases.
Having a query builder that utilizes these types will get us type safe queries, typed outputs from those queries, and a parser that traverses all the way through to the query outputs. This will make the "typing docs with resolved references" an irrelevant problem: if we can type our queries, we'll type whichever references we happen to resolve, along with whatever else we want to do in our groq queries.
My big issue with this is groq is not small. Typing docs was relatively straightforward and not fragile, creating a typed query builder for everything groq can do is not going to easy or straightforward, will grow scope massively, and be prone to bugs.
The text was updated successfully, but these errors were encountered: