Replies: 4 comments 5 replies
-
|
❤️ |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for starting this thread! I went through and re-read the original PR that introduced normalization, #43945, and in particular found a relevant comment from @jonathanhefner:
The good news is that the type decoration mechanism was moved to ActiveModel in #44666 (specifically e0a55b0) so that shouldn't be a blocker anymore. @jonathanhefner would you have any objection to reviewing a PR like the one described? |
Beta Was this translation helpful? Give feedback.
-
|
#53887 has been merged into |
Beta Was this translation helpful? Give feedback.
-
|
@tmaier Thanks for the work on adding normalizes. I was really looking forward to use that and tried wiring it into a non–Active Record project (we’re using Aws::Record models which is backed by ActiveModel). I hit a NoMethodError on decorate_attributes: the new module assumes the AR attribute decorator stack is present, but ActiveModel::Model/Aws::Record classes don’t provide those hooks. It would be great if the API could either fall back to a plain ActiveModel implementation or document that it’s AR-only (because the title is maybe a bit misleading); otherwise consumers like us (running without ActiveRecord) can’t adopt it and have to keep custom normalization concerns. Happy to share more detail if it helps. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Rails 7.1 introduced
ActiveRecord::Normalization- a powerful feature that elegantly handles input normalization for database-backed models. It provides a clean, declarative way to ensure data consistency right at the attribute level.However, Rails applications aren't built on ActiveRecord alone. At their core, many Ruby objects in a Rails app inherit behavior from ActiveModel - the foundation that provides validations, callbacks, and other model-like functionality without database persistence.
These ActiveModel objects (like Form Objects, Value Objects, or API Resource objects) often need the same kind of input normalization, but currently can't benefit from this new feature. For example:
I propose extracting the core normalization features from ActiveRecord into ActiveModel. This would make this powerful feature available to all objects that include ActiveModel, while keeping ActiveRecord-specific enhancements where they belong.
Here's how it could look:
This would require some refactoring to separate ActiveRecord-specific functionality from the core normalization logic, but would bring consistent data normalization to more parts of our Rails applications. What are your thoughts on this approach?
Beta Was this translation helpful? Give feedback.
All reactions