Events as first-class Rails citizens

Events in Funes aren’t a separate idea bolted onto Rails — they’re first-class citizens of the same stack you already use, at the same level as an ActiveRecord model. You wire them into the UI, the controller, the I18n files, and the request cycle the exact same way: ActiveModel validations, form_with, strong parameters, the persisted?/errors cycle, the same activemodel.attributes and activemodel.errors translation keys. An event append is one new method (append) on top of patterns you’ve used for years.

(If you’re new to the event class itself, see the Event concept for what an event is and how it differs from an ActiveRecord model.)

The pages below walk through the everyday Rails tasks where this parity shows up:

• Render events in a form — pass an event to form_with and let the standard helpers handle labels, fields, and errors.
• Append events from a controller — build the event from strong params, call .append, and read persisted? just like save.
• Render 404s from empty streams — projected_with returns the materialization model on a hit and raises ActiveRecord::RecordNotFound on a miss, so Rails renders a 404 automatically — no rescue code needed.
• Translate attributes and messages — the same activemodel.attributes and activemodel.errors I18n keys you already use, plus the two Funes-specific keys for rejected appends.

Go further

• Coordinate appends with sibling writes via the Atomic writes recipe.
• Attach acting-user and request context to every event with the Attach meta information to events recipe.

---

Table of contents

• Render events in a form
• Append events from a controller
• Render 404s from empty streams
• Translate attributes and messages