Add Action Filters Order section

[ydakuka]

It is similar to this rule, but for action filters.

ref: https://dev.to/timkrins/an-experiment-with-controller-action-callbacks-in-rails-c3p

[andyw8]

I agree with the rule, but as with Callbacks Order, I think it's sufficient to give a small example (e.g. two filters) and have a link to the full list (e.g. the post referenced above).

[ydakuka]

have a link to the full list (e.g. the post referenced above).

I couldn't find this information, specifically the list, in the official Rails guide.

I think it's sufficient to give a small example (e.g. two filters) and have a link to the full list (e.g. the post referenced above).

Done.

[pirj]

This feels unnecessary

[ydakuka]

All bad examples?

[pirj]

Is there a reason to use an append/prepend declarations in the same class as with regular before/after?

[ydakuka]

Is there a reason to use an append/prepend declarations in the same class as with regular before/after?

Yes, I use them in my project, especially when working with built-in action filters from gems (for example, to run recaptcha checks before devise's built-in action filters). Otherwise, I use action filter without prepend_.

[pirj]

Aren’t prepend before or append after just aliases of before/after just like rspec hooks?

[ydakuka]

append_#{callback}_action is alias for #{callback}_action. Ref: https://github.com/rails/rails/blob/main/actionpack/lib/abstract_controller/callbacks.rb#L250C26-L250C26

[pirj]

This is getting complicated with inheritance and concerns.
When it comes to a point where order matters, isn’t it a sign that a different approach is needed?

[ydakuka]

I don't think that the action filters order will significantly impact the complexity of the code. Instead, it provides clarity in understanding the order in which the action filters are executed.

I try to avoid inheriting controllers other than inheriting from the application controller.
And as for the concerns, I haven't had any problems with them other than this one.

[pirj]

We have a related guideline https://github.com/rubocop/rails-style-guide#lexically-scoped-action-filter
But it doesn’t tell not to use filters in inherited classes or concerns.
I believe that complex inheritance chain is sometimes a necessity.

The consequence on our case is that the order of those filters is hard to predict. And ordering just local ones would just solve part of this disorder.

[ydakuka]

And ordering just local ones would just solve part of this disorder.

We would have the "correct" order in all controllers. And even with inherited controllers or concerns, the code would still be easier to read. At least it definitely won’t be more difficult.