feat: add result hooks
🔗 Linked issue
#1057
❓ Type of change
- [x] 📖 Documentation (updates to the documentation or readme)
- [ ] 🐞 Bug fix (a non-breaking change that fixes an issue)
- [ ] 👌 Enhancement (improving an existing functionality like performance)
- [x] ✨ New feature (a non-breaking change that adds functionality)
- [ ] ⚠️ Breaking change (fix or feature that would cause existing functionality to 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
- [x] I have linked an issue or discussion.
- [x] I have updated the documentation accordingly.
Live Preview ready!
| 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?