Open GerryWilko opened 11 months ago
Name | Edit | Preview | Latest Commit |
---|---|---|---|
Content | Edit on Studio ↗︎ | View Live Preview | 029bc0eb570b581714da74e254976357ef506bb9 |
@Atinux Would you or another maintainer have a chance to review this PR?
Many thanks in advance!
Can't we use await queryContent('articles').find().then(res => res.map(c => articleSchema.parse(c)))
to parse contents with schema?
In current version I'd rather not to add this feature and one of core features. This is something we can consider in next major release.
Also, we will have better type support in next version and this might add more breaking change for migration.
Apologies for the delay.
So I did consider this approach however it is quite limiting in some respects. One of the lovely parts of the chainable nature of the QueryBuilder is that I can wrap up custom elements of my content query into a composable and then allow consumers of this composable to chain on more parts of the QueryBuilder to suit their needs.
If I can't hook into the resolution of the final query then it means that each consumer of the composable must do their own validation once they resolve their query. I thought this PR seemed like a reasonable addition to the queryContent
composable?
@farnabaz do you have any other feedback for this PR?
🔗 Linked issue
1057
❓ Type of change
📚 Description
I have introduced a new feature result hooks. This feature is detailed in #1057.
The primary aim of this feature is to allow for augmentations to the returned type to be performed within the query builder pipeline. This allows users to use libraries like
zod
to assert that the schema of the returned content is valid and expected.I feel this feature will add a more type safe way to query content and throw errors for unexpected content structure earlier in the pipeline.
📝 Checklist