Allow inserting middleware at arbitrary points in the middleware stack #1390
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
|
||
| class API < Grape::API | ||
| use Overwriter | ||
| insert_before Overwriter, CustomOverwriter, message: 'Overwrited again.' |
|
This is excellent, code is spot on. I made minor text or other comments if you could please amend and I'll merge. |
Changes include: * Include the operation when stacking a new middleware The operation gets stored before the rest of the middleware data (class, args and block), and we use it later to determine the order in which the middleware stack will be built. Currently support `insert_after` and `insert_before`, plus `use` that does the same as before. * Implement a new `Grape::Middleware::Stack` class This class contains the functionality to build the middleware stack taking the different operations into account (`use`, `insert_before` and `insert_after`). It's mostly based on `ActionDispatch::MiddlewareStack` with some simplifications. * Build middleware stack for endpoint using `Grape::Middleware::Stack` Keep the same order for default middleware stack with `use` and use the new class's `build` method to determine the real order of the final stack. * Fix small typo in `Grape::Util::StackableValues` (replace `froozen_values` by `frozen_values`). * Update `CHANGELOG` with the PR number.
|
Thanks so much for the quick review and the feedback! I think I have addressed all the comments now, but feel free to add more comments if you find anything else that can be improved :) |
| @@ -3,16 +3,16 @@ module Util | |||
| class StackableValues | |||
| attr_accessor :inherited_values | |||
| attr_reader :new_values | |||
| attr_reader :froozen_values | |||
| attr_reader :frozen_values | |||
There was a problem hiding this comment.
Those froozen values were just extra frozen. Thanks for spotting this ;)
|
Merged. |
ridiculous
pushed a commit
to ridiculous/grape-middleware-logger
that referenced
this pull request
May 12, 2016
* No longer necessary because of the middleware stack added in ruby-grape/grape#1390
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request is inspired by #794. I was using Grape and found myself needing this feature, so I have built a possible way of supporting
insert,insert_afterandinsert_beforein a similar way as Rails does.Adding a new middleware can now be done through
use,insert,insert_afterandinsert_before, and the operation chosen to do so is stacked together with the middleware class, args, and blocks. The stack is built using the operations inGrape::Endpoint#build_stackusing a new classGrape::Middleware::Stack, based onActionDispatch::MiddlewareStackwith some simplifications (for example, only classes are supported for middleware, no symbols or strings, which is being deprecated inActionDispatchin any case).The commit message offers more details on the implementation itself. If anyone has a better idea of how this feature could be implemented I'd be glad to modify my changes to follow a different approach.
This is my first PR in the Grape project and I have tried to follow the same style when adding new tests for the feature and updating the
README, but I'd be more than happy to adapt those according to feedback 😃