WE ARE CURRENTLY WORKING ON A UNIFIED API FOR ERRORS (FOR DRY AND REFORM).

ActiveModel provides a powerful framework for defining callbacks. ActiveInteraction hooks into that framework to allow hooking into various parts of an interaction's lifecycle.

ActiveInteraction type checks your inputs. Often you'll want more than that. For instance, you may want an input to be a string with at least one non-whitespace character. Instead of writing your own validation for that, you can use validations from ActiveModel. These validations aren't provided by ActiveInteraction. They're from ActiveModel. You can also use any custom validations you wrote yourself in your interactions.

Since interactions behave like ActiveModels, we can use ActiveModel validations with them.

The outcome returned by .run can be used in forms as though it were an ActiveModel object.

ActiveInteraction also supports merging errors. This is useful if you want to delegate validation to some other object. For example, if you have an interaction that updates a record, you might want that record to validate itself. By using the #merge! helper on errors, you can do exactly that.

ActiveInteraction provides detailed errors for easier introspection and testing of errors. Detailed errors improve on regular errors by adding a symbol that represents the type of error that has occurred.

Inside #execute, we merge errors. This is a convenient way to move errors from one object to another.

I have a Post object that has_one :schedule with accepts_nested_attributes_for :schedule as well. The latter method sets autosave: true, which unfortunately has the effect of hoisting up errors into the parent object so that the errors object on Post looks like this: (byebug) post.errors.details {:"schedule.publish_at"=>[{:error=>:blank}]}

But ActiveModel doesn't support out of the box argument parsing, e.g. having a datetime attribute be a datetime attribute and a boolean attribute be a boolean attribute.

ActiveModel::Form happened because the "tableless model" presented in RailsCast 219 wasn't as powerful as the "real deal" from RailsCast 193.

ActionForm also can accept ActiveModel::Model instances as a model.

If you include ActiveModel::Validations you can write the same validators as you would with ActiveRecord. However, in this case, our form is just a collection of Contact objects, which are ActiveRecord and have their own validations. When I save the ContactListForm, it attempts to save all the contacts. In doing so, each contact has its error_messages available.