← ClaudeAtlas

rails-controllerslisted

Use when writing thin controllers with concerns, resource-oriented design, and REST patterns
mickzijdel/rails-toolkit · ★ 0 · AI & Automation · score 70
Install: claude install-skill mickzijdel/rails-toolkit
# Rails Controller Patterns ## Pattern 1: Thin ApplicationController with Concerns The base controller is just a composition of concerns plus a few global settings. All logic lives in the included modules. ```ruby class ApplicationController < ActionController::Base include Authentication include Authorization include BlockSearchEngineIndexing include CurrentRequest, CurrentTimezone, SetPlatform include RequestForgeryProtection include TurboFlash, ViewTransitions etag { "v1" } stale_when_importmap_changes allow_browser versions: :modern end ``` **Don't let `ApplicationController` become a dumping ground.** Because it's already a grab-bag, every new method feels free — "will one more method among 25 really hurt?" — and the file grows into a pile of unrelated helpers (current-user checks, default redirects, `production?`/`staging?` environment checks, `www`-canonicalisation, response-header setters, …) that nobody dares move or delete because they might be referenced from anywhere. That's not a crisis, but it's real cognitive load on every controller in the app. When you add a method to `ApplicationController` — or find one already bloated — apply three rules: 1. **Group related methods and label each group with a comment.** Similar methods should sit together, not be scattered, so the next reader can scan the file. 2. **Don't make a method globally accessible unless it needs to be.** A method that backs a `before_action` running on every request