1
0
Fork 0
mirror of https://github.com/rails/rails.git synced 2022-11-09 12:12:34 -05:00

Add guide for inline around_action

This commit adds a test to ensure the behavior of inline `around_action`
calls, as well as a change to the guides to call out this alternate use of
`around_action`.

Closes #37616
This commit is contained in:
John Crepezzi 2019-11-15 10:18:37 -08:00
parent b674f04756
commit 012b1e3281
2 changed files with 31 additions and 0 deletions

View file

@ -546,6 +546,31 @@ class FilterTest < ActionController::TestCase
end
end
def test_around_action_can_use_yield_inline_with_passed_action
controller = Class.new(ActionController::Base) do
around_action do |c, a|
c.values << "before"
a.call
c.values << "after"
end
def index
values << "action"
render inline: "index"
end
def values
@values ||= []
end
end.new
assert_nothing_raised do
test_process(controller, "index")
end
assert_equal ["before", "action", "after"], controller.values
end
def test_after_actions_are_not_run_if_around_action_does_not_yield
controller = NonYieldingAroundFilterController.new
test_process(controller, "index")

View file

@ -753,6 +753,12 @@ end
Note that the filter in this case uses `send` because the `logged_in?` method is private and the filter does not run in the scope of the controller. This is not the recommended way to implement this particular filter, but in more simple cases it might be useful.
Specifically for `around_action`, the block also yields in the `action`:
```ruby
around_action { |_controller, action| time(&action) }
```
The second way is to use a class (actually, any object that responds to the right methods will do) to handle the filtering. This is useful in cases that are more complex and cannot be implemented in a readable and reusable way using the two other methods. As an example, you could rewrite the login filter again to use a class:
```ruby