Solving the withParams global middleware issue
See original GitHub issueCurrently a withParams
middleware that targets request.params
cannot be injected upstream as global middleware, because at this point, params would have not been set (to be spread into the request).
import { Router } from 'itty-router'
import { withParams } from 'itty-router-extras'
const router = Router()
// currently works
router
.get('/:id', withParams, ({ id }) => new Response(id))
// currently fails
router
.all('*', withParams)
.get('/:id', ({ id }) => new Response(id))
Proposed Solution
- Pass
request.proxy || request
through to handlers… middleware can inject a proxy (if needed) to trigger this. This costs about ~5 bytes. - Middleware can create a Proxy around the request on
request.proxy
and effectively watch the request (for loggers and such), or modify how they read things (e.g. withParams intercepts “gets” to the request proxy and find the values in therequest.params
)
After (Line 12)
This allows a middleware upstream to watch any change on the request itself, including (but not limited to) request.params
, and fire appropriately. It also allows each middleware to proxy the existing proxy, meaning multiple middleware can watch independent request props without worrying about collisions.
With this, an upstream withParams
could be defined as follows, then downstream changes to params would trigger the proxy (assigning params into the request).
Issue Analytics
- State:
- Created 2 years ago
- Comments:5 (4 by maintainers)
Top Results From Across the Web
filesystem middleware doesn't work for routes with params #834
When using the filesystem middleware for a route that contains parameters, like /:myparam/web , it doesn't work. Code snippet. The following ...
Read more >Inspecting constructor parameters inside an autofac middleware
I'm using Autofac as my DI container. What I'd like is to have Autofac resolve the dependencies of class C using the parameter...
Read more >Middleware - Laravel - The PHP Framework For Web Artisans
The withoutMiddleware method can only remove route middleware and does not apply to global middleware. Middleware Groups. Sometimes you may want to group ......
Read more >5.x API - Express.js
Returns middleware that only parses JSON and only looks at requests where the Content-Type header matches the type option. This parser accepts any...
Read more >[Solved]-Rails issue with params hash-ruby - appsloveworld
[Solved]-Rails issue with params hash-ruby. Search. score:1. Accepted answer. Modifying your code a little bit to get @people.each_with_index do |p,i| ...
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 still can’t believe you came up with this so fast…
Where we’ve left it for the night… by simply passing
request.proxy || request
into thehandle()
calls, we don’t have to explicitly setrequest.proxy
upfront in itty, but simply honor downstream injections of it. This does two things:request.proxy = new Proxy(request, { whatever })
.This is important, because it can not only allow things like
withParams
to modify theget
into the request [proxy] that the handlers see, but things can actually watch for future changes by modifying theset
path. This could be useful for loggers that are set up to log downstream changes to the request, for instance!Example test case showing some of this power in action: