Don’t Conflate Helpers with the Domain
Learn about helpers and why we should not confuse them with our domain.
We'll cover the following...
Helpers are handy, yet also a magnet for mess and unsustainability. We are not going to give a perfectly clean and sustainable solution here, but we can help clarify the issues with helpers, explain the best way to use them, and help ease some of the confusion.
Helpers are a way (the only way) to export methods to be available to a view. Any method defined in app/helpers/application_helper.rb will be included and available to all our views. Helpers can also be added via the helper_method in a controller, which will import methods from a class, module, block of code, or really anywhere.
The main problem that comes up around helpers is the sheer volume of them. Because they exist in a single global namespace, the more helpers there are, the harder it is to avoid name clashes and the harder it is to find helpers to reuse. It’s just not feasible to expect engineers to read through tons of helpers to figure out whether what they need exists.
An extreme way to deal with this problem is to ban the use of helpers entirely. We could be successful with this approach, but we’d need an answer for where code goes that does what a helper would normally do. Those approaches, usually called presenters, have their own problems, which we’ll talk about. But even a nuanced approach that clearly defines what code should be in a helper and what shouldn’t still requires answering questions about where all the code we need should end up. Of course, helpers generate HTML, making them a great place to inject security vulnerabilities.
The reality is ...