-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Allows for a block of code to always run after the endpoint #1864
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
Conversation
is it a different funcionality as this one #before-and-after? |
@LeFnord |
… ok, something like an |
Difference would be that this is not run before. |
nice … please update above readme section with this, thanks |
I don't think so; the implementation looks like a missing complementary part for
maybe this can be solved by using an endpoint middleware(the spec) |
I've updated the lifecycle clarifying how this will run. I agree that it could be sorted by Middleware @dm1try but I do feel like having an |
Users might be confused by the current implementation, as the description hints that before do
@state = true
end
ensure_block do
@state # error
end Moreover according to the ordering in the current middleware stack,
btw, the same behavior that proposed here can be emulated by using filters middleware without providing anything new: use Grape::Middleware::Filter, after: -> { do_something } |
I like the syntactic sugar of I think @dm1try has a very valid point (nice catch) about scope of execution and corresponding |
Nice catch @dm1try, I'll give it a go at moving the scope, this was just a simple MVP. Regarding wording, I went for We could go with things like |
How do others feel about |
after some thought I think I like |
+1 for |
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.
Looks great. Only some nitpicky comments around my English language OCD
README.md
Outdated
|
||
Blocks can be executed before or after every API call, using `before`, `after`, | ||
`before_validation` and `after_validation`. | ||
If the API fails the `after` call will not be trigered, if you need code to execute for sure | ||
use the `finally` |
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.
Missing period.
README.md
Outdated
4. `after_validation` (if Validation Successful) | ||
5. _the API call_ (if Validation Successful) | ||
6. `after` (if Validation & API Successful) | ||
7. `finally` (ALWAYS) |
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.
Nitpicking, let's not SHOUT :) I would make all of the comments lowercase (upon successful validation
, always
, etc.)
@@ -3121,6 +3124,13 @@ before do | |||
end | |||
``` | |||
|
|||
You can ensure a block of code runs after every request (including failures) with `finally`: |
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.
Add a space below.
README.md
Outdated
You can ensure a block of code runs after every request (including failures) with `finally`: | ||
```ruby | ||
finally do | ||
This.block(of: code) # Will definetely run after every request |
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.
maybe just # this code will run after every successful or failed request
, cause This.block(of: code)
is not ruby
lib/grape/dsl/callbacks.rb
Outdated
|
||
# Allows you to specify a something that will always be executed after a call | ||
# API call. Unlike the `after` block, this code will run even on | ||
# unsuccesful requests |
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.
Add a period after requests
.
lib/grape/endpoint.rb
Outdated
|
||
# status verifies body presence when DELETE | ||
@body ||= response_object | ||
# The Body commonly is an Array of Strings, the application instance itself, or a File-like object |
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.
lowercase body
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'm merely moving this around but happy to address this anyway)
I'm cool with this change if @dmitry is cool with this change? |
Addressed |
#1865
Motive: Sometime we do things like logging, or open sessions, or other actions during an API request and we want to make sure those actions are wrapped up afterwards.
This introduces a DSL way of handling this after every request on an API