← ClaudeAtlas

rails-modelslisted

Use when writing ActiveRecord models with concerns, validations, callbacks, scopes, and associations
mickzijdel/rails-toolkit · ★ 0 · AI & Automation · score 70
Install: claude install-skill mickzijdel/rails-toolkit
# Rails Model Patterns ## 1. Concern Architecture Extract cohesive behaviors into concerns. Class-level declarations (`has_many`, callbacks, scopes) go in the `included` block; instance methods outside it. ```ruby # app/models/concerns/eventable.rb module Eventable extend ActiveSupport::Concern included do has_many :events, as: :eventable, dependent: :destroy end def track_event(action, creator: Current.user, board: self.board, **particulars) if should_track_event? board.events.create!(action: "#{eventable_prefix}_#{action}", creator:, board:, eventable: self, particulars:) end end def event_was_created(event) end private def should_track_event? true end def eventable_prefix self.class.name.demodulize.underscore end end ``` ```ruby # app/models/card.rb — a model is mostly a composition of concerns class Card < ApplicationRecord include Assignable, Broadcastable, Closeable, Eventable, Mentions, Pinnable, Postponable, Searchable, Statuses, Taggable, Watchable end ``` --- ## 2. Template Method Pattern in Concerns The empty/default methods above (`event_was_created`, `should_track_event?`, `eventable_prefix`) are hooks. Models customize the generic concern by overriding them in a namespaced concern: ```ruby # app/models/card/eventable.rb module Card::Eventable extend ActiveSupport::Concern include ::Eventable # :: prefix avoids namespace conflicts def event_was_created(event) transactio