-
-
Notifications
You must be signed in to change notification settings - Fork 3.2k
emit more events #1395
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
base: master
Are you sure you want to change the base?
emit more events #1395
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #1395 +/- ##
===========================================
- Coverage 100.00% 99.79% -0.21%
===========================================
Files 4 4
Lines 487 496 +9
Branches 136 137 +1
===========================================
+ Hits 487 495 +8
- Partials 0 1 +1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
all these events can implemented in handleRequest(ctx, fnMiddleware) {
const res = ctx.res;
res.statusCode = 404;
const onerror = err => ctx.onerror(err);
const handleResponse = () => {
this.emit('respond', ctx);
respond(ctx);
}
onFinished(res, err => {
onerror(err);
this.emit('responded', ctx);
});
this.emit('request', ctx);
return fnMiddleware(ctx).then(handleResponse).catch(onerror);
}And I'm not sure if we really need to add the handleRequest(ctx, fnMiddleware) {
const res = ctx.res;
res.statusCode = 404;
const onerror = err => ctx.onerror(err);
const handleResponse = () => respond(ctx);
onFinished(res, err => {
onerror(err);
this.emit('respond', ctx);
});
this.emit('request', ctx);
return fnMiddleware(ctx).then(handleResponse).catch(onerror);
} |
|
I would like to keep pre-send event ('respond' or if you suggest to rename it), as a good way to adjust context after all middleware but before sending to the network (there are some real world use for this event), don't see how it can be confusing while being documented, but if you have a rename suggestion - please do! |
|
Yea, sorry, I read this wrong. |
|
need test cases for this feature |
lib/application.js
Outdated
| const onerror = err => ctx.onerror(err); | ||
| const handleResponse = () => respond(ctx); | ||
| const onerror = err => { | ||
| if (null != err) ctx.onerror(err); |
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.
This is breaking change.
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.
What does it breaks?!
| this.once(responding, () => this.emit('respond', ctx)); | ||
|
|
||
| const onerror = err => { | ||
| if (null != err) { |
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.
the old code will execute onerror no matter the err is null or not. So I think this is a breaking change.
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.
@fengmk2 onerror in current implementation just returns immediately if err is null, so, nothing breaks here actually.
| - Many properties on `ctx` are defined using getters, setters, and `Object.defineProperty()`. You can only edit these properties (not recommended) by using `Object.defineProperty()` on `app.context`. See https://github.com/koajs/koa/issues/652. | ||
| - Mounted apps currently use their parent's `ctx` and settings. Thus, mounted apps are really just groups of middleware. | ||
|
|
||
| ## Events |
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.
thanks for this doc, very useful for a PR
| }) | ||
| ``` | ||
|
|
||
| ### Event: 'respond' |
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 don't see how this or the request event have any benefit over regular middleware
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.
it actually has less benefit because you cannot use async functions
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.
There is no need to have advantage or disadvantage and not always sync call is inferior to async call from application point of view. If you follow Node.JS core development strategy then you certainly will notice “mix and match” innovation in handling async flow - once was added into events core module, finished, Readable.from(AsyncIterator), and Readable[AsyncIterator] into the stream - so, modern Node.JS is inviting to pick events, streams or Promises whatever solves problem more efficiently OR USE THEM ALTOGETHER. If Koa is the EventEmitter why it doesn’t emit any lifecycle events apart of error and why event handlers should be considered inferior?
| }) | ||
| ``` | ||
|
|
||
| Note: `respond` event may not be emitted in case of premature socket close (due to a middleware timeout, for example). |
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.
exceptions like this make it less useful and more difficult to maintain
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.
It's not an exception - it's a logic of this event because the response in this case never happened.
|
|
||
| ```js | ||
| app.on('responded', ctx => { | ||
| if (ctx.state.dataStream) ctx.state.dataStream.destroy(); |
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 don't understand this use-case. clean up callbacks on streams should be handled when you create and pipe them.
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.
How would you know from the stream that, for example, connection with a client was prematurely lost and not the whole stream was consumed?
| More advanced example, use events to detect that server is idling for some time: | ||
|
|
||
| ```js | ||
| const server = app.listen(); |
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 would actually recommend not doing this in koa. i would do this as a req/res decorator:
const fn = app.callback()
const checkIdle = (fn) => (req, res) => {
// do stuff
return fn(req, res)
}
http.createServer(checkIdle(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.
I probably missing something here as I’m struggling to understand: if you created Koa as an extension of EventEmitter in the first place, why do you consider using events is antipattern and inferior to writing low-level decorator here?
Koa extends
EventEmitterbut doesn't use that fact for anything apart oferrorevent.However, there are lifecycle hooks that have real-world use and otherwise hard to implement. This PR adds 3 events: 'request', 'respond' and 'responded' as well as documenting the fact that
Applicationis an EventEmitter in a more clear way.With these events is also quite possible to build reactive requests handling on base of Koa.