-
-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
emit more events #1395
base: master
Are you sure you want to change the base?
emit more events #1395
Conversation
Codecov Report
@@ 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
Continue to review full report at Codecov.
|
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.
@@ -221,6 +221,68 @@ Note: | |||
- 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
EventEmitter
but doesn't use that fact for anything apart oferror
event.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
Application
is an EventEmitter in a more clear way.With these events is also quite possible to build reactive requests handling on base of Koa.