I’m wondering why Turbolinks::Redirection and Turbolinks::Controller are ancestors of ActionController::API. I suspect that is a bug. Is there any reason we can’t remove it?
I suspect this is because both ActionController::API and ActionController::Base call ActiveSupport.run_load_hooks(:action_controller, self) and gems (like turbolinks) are not checking to see which class they are injecting behavior into.
What are your thoughts?
-Justin
It looks to me like there’s a config option for this here: turbolinks-rails/turbolinks.rb at master · turbolinks/turbolinks-rails · GitHub. It defaults to true if you require the turbolinks gem, but you can set Rails.application.config.turbolinks.auto_include = false to change the behavior.
I don’t know a lot about ActiveSupport’s load hooks, but at first glance it looks like ActionController::API invokes ActiveSupport.run_load_hooks(:action_controller, self), which Turbolinks hooks into. Adding a separate load hook (ie. action_controller_api) would be a breaking change. It’s probably easiest to use the config option, or not require the turbolinks gem if you aren’t using it.
I think that most users want to autoload Turbolinks includes onto ActionController::Base, but not the ActionController::API. So, should Turbolinks be checking to see that the class it’s including it on is not ActionController::API? I think this case goes beyond Turbolinks too. I’m working on breadcrumbs_on_rails which desires to add behavior on ActionController::Base, but not ActionController::API. It seems like there should be a better way, perhaps 3 hooks (action_controller, action_controller_base, action_controller_api)?
-Justin
Keep up to date with Rails on Twitter and This Week in Rails
Policies: Conduct, License, Maintenance, Security, Trademarks