-
Notifications
You must be signed in to change notification settings - Fork 147
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
Add support for a wrapper array in context #52
base: next
Are you sure you want to change the base?
Conversation
8fdfefc
to
ddb4907
Compare
Tests should be passing now, had some linting problems. |
index.js
Outdated
try { | ||
if (fn && context.wrappers) { | ||
context.wrappers.forEach((wrapper) => { fn = wrapper(fn) }) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not that it matters, but I find wrapper => { ... }
without ()'s around single argument fat-arrows a bit more pleasant.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know, I would like that too, and I wouldn't like the brackets either, but standard requires both of those.
It sure is less invasive compared to #51, even though it too could be iterable. There's some risk of overuse in user land I guess. |
If this merges (with the koa PR) then I'll make a PR for koa-mount, and make a PR to revert the deprecated generators in koa and add wrapper support for koa-convert. |
It's a little weird to have dependency from within context in compose though, isn't it? |
I guess, but I'm not sure that has much of a practical implication. I've already checked that |
9292019
to
371960b
Compare
The code now throws an error if it doesn't end up with a function (or it ends up with a generator function). I think now that we have wrappers, it makes sense for that to be here. However, this makes the code a bit long. Should we abstract lines 43-52 into it's own module (e.g. |
We could also create |
Okay, I've consolidated the code into another module: https://github.com/PlasmaPower/call-middleware I haven't published the module to NPM yet, and the module references itself as if it was part of koajs. That's why the build is failing. My plan is someone can clone that repo, push it to a koajs repo (forking it removes the issues tab), make any needed changes, publish the module, then the build will pass and this can be merged. I've already checked that with the module there the build passes. |
is this taking |
Yep. It helps preserve the wrappers and ensure the compatibility, but it also makes compose dependent on context to some extent. The alternative is another paramater, like @fl0w implemented. I prefer the former because it's better for the user, but the latter is less opinionated. |
Rebased. Remember tests are failing because they rely on |
This is a new way to implement wrappers (another one was #51).