Do You Need That Validation? Let Me Call You Back About It
summary
Shows that before_validation callbacks cause hidden bugs (example: auto-setting event datetimes that broke tests) and huge test/setup cost (one case forces creating ~23 rows). Examines concrete alternatives: plain ActiveModel form objects with explicit save flow, the active_type inheritance trick, Elixir-style change sets (used in Phoenix) that tie allowed params to validations, and Trailblazer/Reform + dry-validation operations. Demonstrates what gets built, why callbacks run unexpectedly, and why change sets or scoped validators often work better.
AI-written summary · about
chapters (10)
- 0:00Introduction
- 1:03The problem with callbacks
- 5:51Validations and complexity
- 12:45Affordances in design
- 20:33Existing rails solutions
- 24:11Form objects
- 26:22Inheritance-based approach
- 28:21Change sets
- 33:23Operations and validators
- 38:13Conclusion and takeaways
related talks
31mOff the Rails: Validating non-model classes with…ActiveModel?
24mValidate Me! - Demystifying Rails Validators
12mWAT!! ActiveRecord Callbacks
21mForm Validation Done Right
38mRails hurts, because you're using it wrong. Let's fix that
41mAn Intervention for ActiveRecord
27mDecouple Your Models with Form Objects
26mDon't Rewrite Your Framework