Why is Turbolinks::Redirection an ancestor of ActionController::API?

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: https://github.com/turbolinks/turbolinks-rails/blob/master/lib/turbolinks.rb#L21. 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