-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Getting matched route #14
Comments
I see no easy way to get the matched route pattern without hurting performance. However, PRs are welcome if you can fix it. Since Koa middleware run in the order that they declared, if a middleware want to do something in the upstream middleware, it will require a lot of hack. I think a good middleware should be self-contained and has no black magic that can manipulate upstream middleware. Therefore, this feature should be in your Koa application, not in a module. |
koa-tree-router is already taking We can just call that exposed function in another middleware (only if we'd like to log the matched route pattern early in the middleware stack). No routing happens until koa-tree-router is reached, just as before. So no change for people who don't need this functionality. The only downside would be that if I log the matched route pattern, the route resolution happens twice. But since this is already up to 11 times faster than koa-router it's no problem. Plus I wouldn't be logging it in all cases. And people who aren't logging it would see no performance penalty at all. |
What is the function that you want the router to expose? |
Something like |
Let me think about it. Meanwhile, PRs are welcome. |
Can't you just prepend a middleware for each // Replace this
router.get('/path', middleware)
// with
router.get('/path', addToLogger('/path'), middleware) I think An equivalent alternative is to use router.get('/path', compose([addToLogger('/path'), middleware])) |
@dosentmatter That's duplication as well. If you change Plus giving us the ability to call a generic function like I've suggested can be used in several ways beyond this. |
@rightaway It is duplicate in my example, but I mentioned above
So you can have a helper function that takes the input path This is just a workaround for the time being since the feature doesn't exist. Though it could be part of how this feature is eventually implemented. |
As a workaround not a solution I understand. |
Is there a way to get the matched route pattern as opposed to the actual url (
ctx.request.url
)?Also this middleware appears near the end of all my middleware (after the ones that need to go before it like logging and permissions). But I'd like to be able to log the matched route pattern in the earlier middleware. Something like a
router.getMatchedPattern
function we could call at the beginning of our middleware to resolve the matched pattern which we can use throughout the other middleware. What do you think of such feature?The text was updated successfully, but these errors were encountered: