-
Notifications
You must be signed in to change notification settings - Fork 395
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
Fix #1805 Include headers in the request object of custom route handlers #1806
Conversation
Codecov Report
@@ Coverage Diff @@
## main #1806 +/- ##
==========================================
+ Coverage 82.11% 82.15% +0.04%
==========================================
Files 18 18
Lines 1526 1519 -7
Branches 442 435 -7
==========================================
- Hits 1253 1248 -5
Misses 175 175
+ Partials 98 96 -2
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
Hey @E-Zim, thanks for working on this! Since I am a bit busy for other things right now, I won't be able to review this PR this week. If other assigned reviewers can do within a few days, I will defer to them for PR approvals. |
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.
Great work 🥇 excellent detailed explanation in the PR totally help me get up to speed on the context
Left a small naming comment for the tests
src/receivers/HTTPReceiver.spec.ts
Outdated
@@ -504,11 +504,13 @@ describe('HTTPReceiver', function () { | |||
|
|||
fakeReq.method = 'GET'; | |||
receiver.requestListener(fakeReq, fakeRes); | |||
assert(customRoutes[0].handler.calledWith({ ...fakeReq, params }, fakeRes)); | |||
let message = Object.assign(fakeReq, { params }); |
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.
Since this is a test and message
is a value we expect and compare against, I think renaming it something more descriptive such as expectedMessage
or something similar would provide more context
Let me know what you think
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.
That is much more clear, nice callout! I have gone and updated all of the tests with this 👍
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.
LGTM
Summary
The changes in this PR assign
req.headers
to the request object in handlers of custom routes and adds an example to the docs. Fixes #1805.Reviewers
With the changes on this branch, verify that request headers are displayed in static and dynamic routes using both Socket Mode and HTTP. You can check this by navigating to these routes with the following code:
http://localhost:3000/health
http://localhost:3000/music/jazz
Diagnostic notes
For those curious about the changes, some findings are below. This was a neat exploration into the
Symbol
object and how objects are spread! So...Access to certain attributes of the
req
object (such asreq.headers
) was lost in the spread operator in the line below:However, similar attributes would appear when logging the
req
object, just in aSymbol
form, like so:As a result of being represented as symbols, these weren't expanded by the spread operator. From the MDN docs:
So this was causing the
{ ...req, params }
object to not include all attributes ofreq
!To include the missing attributes and the
params
object, a call toObject.assign()
was used instead:This
Object.assign()
method "copies all enumerable own properties", which includes these symbols and no longer requires a type assertion, so thereq.headers
attribute returns!Requirements