Implement helpers proxy in controller instance level#24866
Conversation
There were a lot of protected instance variables in AbsctractController::Rendering that were related to Action Controller and Action View. Moving to ActionController::Base's protected instance list we make it closer to where they are really defined.
There was a problem hiding this comment.
There's also assert_includes :)
|
LGTM and like the idea. Should we make this available for Action Mailer too? |
Yeah, that makes sense. Neither of them are available in mailers. |
|
So, after checking mailers helpers don't use |
9ef054e to
c41b823
Compare
It is a common pattern in the Rails community that when people want to
:xa
use any kind of helper that is defined inside app/helpers they includes
the helper module inside the controller like:
module UserHelper
def my_user_helper
# ...
end
end
class UsersController < ApplicationController
include UserHelper
def index
render inline: my_user_helper
end
end
This has problem because the helper can't access anything that is
defined in the view level context class.
Also all public methods of the helper become available in the controller
what can lead to undesirable methods being routed and behaving as
actions.
Also if you helper depends on other helpers or even Action View helpers
you need to include each one of these dependencies in your controller
otherwise your helper is not going to work.
We already have a helpers proxy at controller class level but that proxy
doesn't have access to the instance variables defined in the
controller.
With this new instance level helper proxy users can reuse helpers in the
controller without having to include the modules and with access to
instance variables defined in the controller.
class UsersController < ApplicationController
def index
render inline: helpers.my_user_helper
end
end
c41b823 to
541a51e
Compare
|
❤️ |
|
Sweet ❤️ |
…se-notes [ci skip] Release notes: Add PR #24866 to release notes
|
❤️ |
|
|
||
| # Provides a proxy to access helpers methods from outside the view. | ||
| def helpers | ||
| @_helper_proxy ||= view_context |
There was a problem hiding this comment.
Just curious - why not use view_context.some_helper_method in the controller instead of helpers.some_helper_method?
There was a problem hiding this comment.
Because view_context is not cached and it working view_context is just an implementation detail that I plan to change some point in the future.
Adds a `#helpers` method that works as a proxy for components to access helper methods through. Inspired by a similar feature in Rails by @rafaelfranca: rails/rails#24866 Resolves: ViewComponent#92
Adds a `#helpers` method that works as a proxy for components to access helper methods through. Inspired by a similar feature in Rails by @rafaelfranca: rails/rails#24866 Resolves: ViewComponent#95
It is a common pattern in the Rails community that when people want to
use any kind of helper that is defined inside app/helpers they includes
the helper module inside the controller like:
This has problem because the helper can't access anything that is
defined in the view level context class.
Also all public methods of the helper become available in the controller
what can lead to undesirable methods being routed and behaving as
actions.
Also if you helper depends on other helpers or even Action View helpers
you need to include each one of these dependencies in your controller
otherwise your helper is not going to work.
We already have a helpers proxy at controller class level but that proxy
doesn't have access to the instance variables defined in the
controller.
With this new instance level helper proxy users can reuse helpers in the
controller without having to include the modules and with access to
instance variables defined in the controller.