Activity feed

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↵
```

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.

Tested, it works. `self` does indeed point to the `view_context` in the helper. Verified by printing `object_id`s.

Then how would you call this`index` from a helper method?

 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.

 19 unchanged lines collapsed
    vc.some_helper_method↵
  end↵
↵
  def some_helper_method↵
    # …
 3 unchanged lines collapsed

If so, there might be a way to bind them to the `view_context`. Or I could definitely pass the `view_context` explicitly as the first parameter.parameter:↵
↵
So instead of↵
↵
```ruby↵
@helper_module.instance_method(@action_name).bind_call(view_context)↵
```↵
↵
I would do↵
↵
```ruby↵
@helper_module.send(@action_name, view_context)↵
```↵
↵
And the parameter list of each Hiccdown method would start accordingly:↵
↵
```ruby↵
module ProductsHelper↵
  def self.index vc #, …↵
    # …↵
  end↵
end↵
```

Does that mean they wouldn’t have access to the `view_context`? If so, calling helper methods from inside these class methods wouldn’t be possible.

Hiccdown methods should live in Rails helpers.helpers as instance methods.