Hiccdown methods should live in their own, separate modules. How about they are called ‘renderers’?↵
↵
```ruby↵
module ProductsRenderer↵
  def self.index vc, # …↵
    vc.some_helper_method↵
  end↵
end↵
```

 6 unchanged lines collapsed
  end↵
end↵
```end↵
end↵
```↵
↵
A benefit of this approach is that, when people start a new Rails app, they may end up putting whatever they’d otherwise put in a helper in a renderer, since renderers have the benefit of having unambiguously resolvable method names.

Hiccdown methods should live in their own, separate modules. How about they are called ‘renderers’?↵
↵
```ruby↵
module ProductsRenderer↵
‘displays’?↵
↵
```ruby↵
module ProductsDisplay↵
  def self.index vc, # …
 5 unchanged lines collapsed
A benefit of this approach is that, when people start a new Rails app, they may end up putting whatever they’d otherwise put in a helper in a renderer,display, since renderersdisplays have the benefit of having unambiguously resolvable method names.

Hiccdown methods should live in their own, separate modules.classes. How about they are called ‘displays’?↵
↵
```ruby↵
module‘displays’?↵
↵
```ruby↵
class ProductsDisplay
  def self.indexindex vc, # …
    vc.some_helper_method
  end↵
end↵
```↵
↵
A benefit of this approach is that, when people start a new Rails app, they may end up putting whatever they’d otherwise put in a helper in a display, since displays haveend↵
end↵
```↵
↵
Behind the scenes, the Hiccdown gem would need to make the benefit of having unambiguously resolvable method names.instance variables available to the display class:↵
↵
```ruby↵
display = @display_module.new↵
↵
view_context.instance_variables.each do |iv|↵
  display.instance_variable_set(↵
    iv,↵
    view_context.instance_variable_get(iv)↵
  )↵
end↵
```↵
↵
Then:↵
↵
```ruby↵
class ProductsDisplay↵
  def index vc, # …↵
    vc.some_helper_method(@products)↵
  end↵
end↵
```