11 Matching Annotations
  1. Feb 2021
    1. The outcome returned by .run can be used in forms as though it were an ActiveModel object.
    2. You can also create a form object by calling .new on the interaction.
    1. ActiveModel::Form happened because the "tableless model" presented in RailsCast 219 wasn't as powerful as the "real deal" from RailsCast 193.
    1. So how are we going to create a model that doesn’t have a database table behind it? There are several potential solutions including various plugins but we’re going to use the method described in an entry on the Code Tunes blog. This shows a techinque that involves overriding a couple of methods in an ActiveRecord model and then manually defining the columns in the model file rather than in the database table. In our Recommendation model we’ll add in the two overridden methods and then use the column class method to define the columns in a similar way to how they’re defined in a migration file.

      Does this still work in Rails 6? I wonder.

    1. Why process, not save? This is entirely up to you. However, it's good to stay consistent across your team so there's no confusion. I began using save but found there are some cases for forms where you aren't saving anything, such as when you are just triggering a job or push-notification. I found using process fits more cases so that's what I use. This is also typically the only method that is public on my forms.

      process is a good name, but I think this is evidence that this object is not the form object itself, but a form processor (as I like to call it) or a "workflow" object (like https://github.com/gogogarrett/reform_example/blob/master/app/forms/workflows/user_workflow.rb), which wraps a form object.

    2. I've been over the use case for form objects in this post on moving away from fat models but wanted to go into more detail on how and why I use them here. I really believe in the utility of these objects; their ability to abstract and isolate logic in a simple and effective manner is unmatched, IMO.
    3. The basic classification of a form object is a class that contains writable attributes, validations and logic to persist the attributes to ActiveRecord objects. These forms can also include other side-effects like background job triggers, emails, and push-notifications etc. The simplest way to understand the concept is to think of them as a representation of a controller action where all of the business logic that happens in that controller action is abstracted into a form object.

      This definition may be a bit too broad. Others (like Reform) define it to have smaller scope — only the part where it persists/validates attributes. The other side effects might be better to put in a different location, like the controller action, or a service/processor object that has a form object.