rails-controller-patterns

Rails Controller Patterns

Generate controllers following standard Rails RESTful conventions (7 actions, resourceful routing, before_actions, strong params).

Supporting Documentation

• patterns.md - Detailed controller patterns and examples

Core Principles

1. Thin controllers: Handle HTTP concerns only; delegate business logic to its axis-appropriate home — on Axis A (rails-stack-profiles), native delegates to models and concerns, extracted delegates to service objects
2. RESTful by default: Stick to 7 standard actions; create new resource controllers for custom actions
3. Strong parameters always: Never trust user input; use params.expect (Rails 8+)
4. Consistent responses: redirect_to after success, render :action, status: on failure
5. One resource per controller: Avoid multi-resource controllers
6. Dedicated resource controllers: Prefer Cards::ClosuresController over post :close on CardsController

Strong Parameters: params.expect (Rails 8+)

params.expect replaces params.require().permit() with a cleaner, more secure API. Check Gemfile.lock for Rails version before using.

# Basic
params.expect(post: [:title, :content])

# Arrays
params.expect(post: [:title, tags: []])

# Nested attributes
params.expect(user: [:name, :email, profile_attributes: [:bio, :avatar]])

# Dynamic hash attributes
params.expect(product: [:name, :price, metadata: {}])

# Legacy syntax (Rails < 8)
params.require(:post).permit(:title, :content)

Dedicated Resource Controllers

Treat state changes as resources instead of adding custom member actions. This keeps controllers focused and RESTful.

# Bad - custom actions bloat the controller
resources :cards do
  post :close
  post :reopen
end

# Good - resource controllers
resources :cards do
  scope module: :cards do
    resource :closure      # create = close, destroy = reopen
    resource :pin          # create = pin, destroy = unpin
  end
end