Inferred path parameters fallback to "DefaultParamsType" when specifying "RequestBodyType"
See original GitHub issue- Related to #1073
Current behavior
rest.get<never>('/user/:id', (req) => {
req.params.id // is not an inferred type
req.params // DefaultParamsType
})
Expected behavior
rest.get<never>('/user/:id', (req) => {
req.params.id // is an inferred "string"
req.params // { id: string } (inferred)
})
Issue Analytics
- State:
- Created 2 years ago
- Comments:13 (10 by maintainers)
Top Results From Across the Web
Describing Parameters - Swagger
In OpenAPI, a path parameter is defined using in: path . The parameter name must be the same as specified in the path....
Read more >Routing - Ktor
Routing is the core Ktor plugin for handling incoming requests in a server application. When the client makes a request to a specific...
Read more >Multisite personalization - Globaleaks/GlobaLeaks - IssueHint
Issue Title Created Date Comment Count Updated Date
Use another augmented assignment statement 1 2021‑11‑21 2022‑09‑16
Carousel of our supporters 0 2021‑02‑25 2022‑09‑24
Allow removing or...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I’m sad we didn’t get to ship this to our users. @cmolina, thank you for the fantastic work on this. The change is not forgotten, and I hope once TS will get around generics and we can merge this.
I had a wild thought to try to propagate the path type to the resolver like this:
I have doubts this will work but will give it a try in a playground.