Skip to content
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

Compose middleware #375

Merged
merged 5 commits into from
Feb 6, 2020
Merged

Conversation

barlock
Copy link
Contributor

@barlock barlock commented Jan 17, 2020

Summary

This converts all middleware to be promise based as per #353

Depends on #369

NOTE I didn't include any documentation updates as #369 got giant because of it. I'll follow this with a pr for docs alone.

Requirements (place an x in each [ ])

): Promise<unknown> {
return composeMiddleware(middleware)({
...context,
next: () => Promise.resolve(),
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

An interesting thing to note here, it became quickly obvious to me why koa-compose chose to have their middleware signatures be (ctx, next) instead of just (ctx) with next inside ctx.

The reason here is that one of the purposes of ctx is to be passed around and modified in place, it's very awkward to do that when the processing has to modify the context mid stream. (As next needs to basically be the next function in the chain)

That lead to this object spread here. This will cause some (possibly) weirdness when it comes to listener middleware. Each listener middleware will have it's own context separate from the rest of them... sometimes. It would depend on the shape of context and how it was accessed and changed in processing.

I can see this being sorta helpful (partial isolation of middleware running at the same time), but could lead to unexpected results if folks are used to writing koa style middleware.

For this reason I'd still recommend using koa-style middleware rather than this one. But, if pseudo-backwards-compatibility is still more important, this works for the most part.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correction, not sure why this didn't click before, because all of the listener middleware is run at once, in order for them not to be constantly overriding each other's next function, this must be spread.

Changing the signature would let us not have to do this.

@codecov
Copy link

codecov bot commented Jan 17, 2020

Codecov Report

Merging #375 into @slack/bolt@next will increase coverage by 1.81%.
The diff coverage is 98.61%.

Impacted file tree graph

@@                 Coverage Diff                  @@
##           @slack/bolt@next     #375      +/-   ##
====================================================
+ Coverage             83.56%   85.37%   +1.81%     
====================================================
  Files                     7        7              
  Lines                   505      506       +1     
  Branches                145      144       -1     
====================================================
+ Hits                    422      432      +10     
+ Misses                   54       49       -5     
+ Partials                 29       25       -4
Impacted Files Coverage Δ
src/middleware/process.ts 100% <100%> (+12.5%) ⬆️
src/conversation-store.ts 96.29% <100%> (ø) ⬆️
src/middleware/builtin.ts 82.11% <100%> (-0.29%) ⬇️
src/App.ts 89.69% <96.66%> (+2.33%) ⬆️
src/errors.ts 100% <0%> (+18.75%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5881471...4afd362. Read the comment docs.

@barlock barlock changed the base branch from master to @slack/bolt@next February 3, 2020 17:29
@barlock
Copy link
Contributor Author

barlock commented Feb 3, 2020

Rebased change on new branch: Still interested to discuss #375 (comment)

@barlock barlock marked this pull request as ready for review February 3, 2020 17:30
Copy link
Member

@seratch seratch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I left one comment on a test code but others look wonderful 👍

src/App.spec.ts Outdated Show resolved Hide resolved
@seratch
Copy link
Member

seratch commented Feb 5, 2020

@barlock #393 brought a few conflicts with this PR. I've resolved them by barlock#2.
One positive side effect is that two tests I added detected app.event listener issue in your branch. I'm also trying to fix this in a proper way but I would love to consult you on this.
This was my bad 🙇 Your code works perfectly!

@seratch
Copy link
Member

seratch commented Feb 5, 2020

^ @barlock The test failures were my bad. Your code works perfectly. I think my PR to your branch is ready to merge. Then, I'd love to merge this PR to the @slack/bolt@next branch (finally!).

src/App.spec.ts Outdated Show resolved Hide resolved
src/App.spec.ts Outdated Show resolved Hide resolved
@seratch
Copy link
Member

seratch commented Feb 6, 2020

Thanks @barlock ! I'm sure this PR is ready to merge 🎉

@seratch seratch merged commit f7ca14a into slackapi:@slack/bolt@next Feb 6, 2020
@seratch
Copy link
Member

seratch commented Feb 6, 2020

^ at barlock The test failures were my bad. Your code works perfectly. I think my PR to your branch is ready to merge. Then, I'd love to merge this PR to the @slack/bolt@next branch (finally!).

The issue has not been detected by the existing tests in Bolt v1. The PR #394 addresses the issue for Bolt v1.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants