Custom generators in your Rails app
Sjabloon comes with multiple custom generators for form objects, service objects, presenter object and query objects. They are in fact nothing more than ”Plain Old Ruby Objects” and keep controllers ánd models in check. All of these “objects” serve a different purpose, and greatly help keep a clean, tidy and organised code base.
Form Objects are a great solution where you have to deal with multiple models in one form. For instance an user creates an account where they also have to set up their team. They also work where your “create” and “update” forms are vastly different, thus you rely on a lot of conditional validations in your model. By separating these into different form objects, you keep this logic separate.
rails generate form Signup.
A Service Object is a one-purpose object. They should only do one thing. Examples are: “Sync With Stripe”, ”Fetch From Freshbooks” or “Update Github Pull Request”. Stick to one public api method (in Sjabloon’s case, eg.
ServiceObject.new(id).call). Service Objects work great together with Form Objects (eg. create a customer in Stripe when a new user signs up). Sjabloon also adds a “BaseService” that any Service Object can inherit from to make calls to your service objects a bit cleaner (check it under “app/services/base_service.rb”).
rails generate service SyncWithStripe.
In order to keep your views tidy and clean, you can resort to the Rails-default of “helpers”. The problem with helpers is they are global, furthermore there will be lots of code duplication by looking up models. A more structured way is to use Presenter Objects. Try to make a Presenter Object per component, by doing so they’re easily reusable and don’t get too big.
rails generate presenter Modal.
The Query Object is likely the less used of these for most Rails SaaS apps early on, but when your queries within your controller span multiple lines, it might be worth it to extract it out into a Query Object. A nice extra of a Query Object is they can be reused in controller actions, Presenter Objects, etc. So no code duplication!
rails generate query FindProduct.
The biggest reason to use these community-conventions into your Rails app is to keep your code organised. So when there are multipe lines of logic in your controller actions, use a Form- or Service Object. When you have conditionals in your view, resort to a Presenter. They will help you write cleaner code, you or your new employee will love to work with. As a rule of thumb: reach for these objects when the Rails defaults don’t cut it anymore.
Run each of these generators without any values (eg.
rails generate form) to get help for them.