A few weeks ago, I needed to add some view-related methods to an object. Decorators are my go-to pattern to handle this kind of logic.
Normally, I’d use the draper gem to build decorators. But the app I’m working on used an older and incompatible version of Rails.
So I built a minimal decorator from scratch, added a bunch of extra behaviors, only to end up abstracting all of these away. Follow along!
What I’m working with
My Teacher class has a handful of methods:
- A one-to-many relationship with the Student class.
- Two public methods: one that exposes the maximum number of students a teacher can teach to, and one exposing the available teaching places.
In my views, I want to display a table of teachers where the number of available places for each teacher is backed by a background colour.

I could write the Teacher#colour_coded_availability method in my model like so:
However, models are not the place for methods generating CSS classes. Decorators are!
Drafting a decorator
My decorator should accept an instance of Teacher and expose the colour_coded_availability public method.
Now, I can instantiate my decorator and use it in my views:
When I can call teacher.colour_coded_availability in my views, the method retrieves a CSS class and adds it to the HTML <td> tag.
But if I were to run this code as is, I’d get a beautiful NoMethodError. Why?
My views do not handle instances of Teacher anymore. They handle instances of TeacherDecorator. So, when I’m calling the public methods defined on Teacher, the decorator doesn’t know what to do with them.
My decorator needs to be able to handle both its own public methods and the public methods defined on the underlying record (Teacher, in this case).
And we do that by using Ruby’s method_missing.
Ruby’s method_missing to the rescue
method_missing is how Ruby handles method calls made on objects where said methods are not defined. Ruby passes the method call along the ancestry chain until it can either resolves it or raises a NoMethodError.
When I call @teacher.full_name, I want my decorator to rescue the NoMethodError, and forward #full_name to the underlying instance of Teacher.
To do that, I need to re-open Ruby’s method_missing, add a custom behavior, then allow method_missing to run its normal course.
In this example, I keep the original signature of Ruby’s method_missing.
The only thing I tweak is forwarding the method call to the underlying teacher. I only forward it if the teacher responds to the method. Then, I let Ruby resume its original behavior 1.
Now, @teacher.full_name is properly forwarded to the underlying instance of Teacher.
What would be cool now, is to allow other decorators to share this behavior.
Normalizing the behavior to create other decorators
One way to gather default behavior shared across various decorators is to rely on inheritance. I can create an ApplicationDecorator whose job is to handle instantiation, and forwarding method calls to the underlying record.
Then, I can have my TeacherDecorator inherit from the ApplicationDecorator.
My TeacherDecorator doesn’t need to bother about its initialization since it’s handled by the parent ApplicationDecorator. The only thing I added, is the ability to reference the record as teacher so it’s clearer what kind of record we’re working with.
Ensure Rails default behavior works well
Some Rails native helpers will have a hard time handling my decorator.
Consider this code:
But if @teacher references an instance of my TeacherDecorator, the generated path is teachers/#TeacherDecorator/edit.
How do I make my decorator integrate with Rails default behavior?
I can re-open the to_param method which is responsible for turning (among other things) a record into its id, and delegating its behavior to the record.
Of course, forwarding every Rails default behaviors to the underlying record is not a great strategy (too much complexity). So, how should I do it?
Use Ruby standard SimpleDelegator
SimpleDelegator provides the means to delegate all supported method calls to the object passed into the constructor.
This means that by using SimpleDelegator, I can remove the initialization and the delegation logics from my ApplicationDelegator.
Everything is abstracted away. And it just works™. @record is not available anymore for my TeacherDecorator to reference, but SimpleDelegator exposes a __getobj__ that works exactly as my previous @record ivar.
Final implementation
Here’s what I ended up with:
That’s it! A 30-minute minimal decorator in plain Ruby.
Cheers,
Rémi - @[email protected]
PS: I'm available for hire.
.png)

