HELPERS AREN’T AWESOME
• at least for this task
• they share a global namespace
• aren’t a very oo way of solving the problem
• great for shared logic that doesn't relate to the
object. Use sparingly
I KNOW MODELS!
• also nope
• All these if conditions relate to the display of data
• Don’t overload your model with that level of
• Presenters are a simple class with knowledge of
the model and the view.
• Not a stretch to call them a ViewModel
• Presenters help to achieve adherence to SRP
• A Presenter’s purpose is a decorator who has the
job of massaging the decorated object into a ui/
view friendly manner.
• Taking one object and adding, replacing or
extending its behaviour, whilst allowing access to
the underlying objects methods.
PRESENTERS VS DECORATORS
• A decorator isn’t always a presenter, but a
presenter is always likely to be a decorator.
• This is more in line with a decorator approach
• We just delegate to the underlying object
• ensure you delegate methods to the underlying
• Just create a wrap method to instantiate your
presenter/decorator across multiple records.
• Great for when things start getting more
OTHER VALUE POINTS
• Easy-ish to test
• less conditionals in your views
• happier designers/front end developers
• More objects == harder to learn the codebase
• Don’t introduce them until you need to.
• Railscasts - draper and presenters from scratch