feat: request validation using handler object syntax `validate` and `validateEvent(event)`
🔗 Linked issue
❓ Type of change
- [ ] 📖 Documentation (updates to the documentation, readme, or JSdoc annotations)
- [ ] 🐞 Bug fix (a non-breaking change that fixes an issue)
- [x] 👌 Enhancement (improving an existing functionality like performance)
- [ ] ✨ New feature (a non-breaking change that adds functionality)
- [ ] 🧹 Chore (updates to the build process or auxiliary tools and libraries)
- [ ] ⚠️ Breaking change (fix or feature that would cause existing functionality to change)
📚 Description
This allows inferring type of event by passing a validate function which needs to return the event (as validated). It's simple and allows any kind of validation, throwing an error if invalid input is provided.
📝 Checklist
- [ ] I have linked an issue or discussion.
- [ ] I have updated the documentation accordingly.
Codecov Report
Attention: Patch coverage is 95.90164% with 5 lines in your changes missing coverage. Please review.
Project coverage is 83.19%. Comparing base (
a58d7c9) to head (6f2ea16). Report is 85 commits behind head on main.
:exclamation: Current head 6f2ea16 differs from pull request most recent head 58c0256
Please upload reports for the commit 58c0256 to get more accurate results.
| Files | Patch % | Lines |
|---|---|---|
| src/event/utils.ts | 97.01% | 2 Missing :warning: |
| src/utils/request.ts | 50.00% | 2 Missing :warning: |
| src/event/event.ts | 83.33% | 1 Missing :warning: |
Additional details and impacted files
@@ Coverage Diff @@
## main #496 +/- ##
==========================================
+ Coverage 77.83% 83.19% +5.36%
==========================================
Files 47 32 -15
Lines 4286 3654 -632
Branches 611 545 -66
==========================================
- Hits 3336 3040 -296
+ Misses 933 614 -319
+ Partials 17 0 -17
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
I am wondering if we can alternatively support before:[validate()] to allow multiple validate functions and avoid adding new hook.
The issue is the typing. It might be possible but will be a lot more complex, to create chainable validators. (So output of one becomes input of another.)
It makes sense for type complexity
I am thinking it could give some overhead for when we want to do body normalization, we actually read the body (and an external library can apply schema normalization). Only returning a boolean + typed Event will cause to loose this information (unless the utils support a context caching mechanism for when we later call useValidatedBody AND we use same validation options) vs before hooks or alike method that can do both validation + context injection like before: [useValidatedBody]
Also, it would be nice if we expose a generic utility async validateEvent to extract this functionality and also make it available for non object syntax usages.
Hi, I wish to understand how this change would interact with, or eliminates the need for, the validation options via community packages mentioned in h3's README? https://github.com/unjs/h3#community-packages
Update: Both me and @danielroe need to rethink about whole typing and validation and how it works with downstream (Nitro and Nuxt) types and best type/runtime safely+perf balance which is tricky at the moment. Making it draft until after 1.8 to iterate.
Deploying unjs-h3 with
Cloudflare Pages
| Latest commit: |
58c0256
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://1324ba9c.unjs-h3.pages.dev |
| Branch Preview URL: | https://feat-validate.unjs-h3.pages.dev |
(closing as object syntax removed, we need to build it based on new middleware format)