Search ideas

#327 applies here, too: no access to instance variables inside helper class methods.

Not as of #330, they couldn’t.

Hiccdown methods should live in their own, separate classes. How about they are called ‘displays’?

class ProductsDisplay
  def index vc, # …
    vc.some_helper_method
  end
end

Behind the scenes, the Hiccdown gem would need to make the instance variables available to the display class:

display = @display_module.new

view_context.instance_variables.each do |iv|
  display.instance_variable_set(
    iv,
    view_context.instance_variable_get(iv)
  )
end

Then:

class ProductsDisplay
  def index vc, # …
    vc.some_helper_method(@products)
  end
end

That’s way too verbose.

They are: vc.instance_variable_get(:@foo)

Instance variables are not available inside the methods.

I’m trying this now. Having to prepend every invocation of a helper method with vc. is getting really old really fast.

Hiccdown methods should live in their own, separate modules. How about they are called ‘displays’?

module ProductsDisplay
  def self.index 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 have the benefit of having unambiguously resolvable method names.

Superseded by #323. This comment was generated automatically.

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

Tested, it works.

Test this!

Maybe ‘Display’. ProductsDisplay

I don’t like the term ‘renderer’ yet. It’s too loaded with meaning, what with Rails already having a render method in controllers and another render method in views…

Superseded by #317. This comment was generated automatically.

Then how would you call index from a helper method?

Hiccdown methods should live in their own, separate modules. How about they are called ‘renderers’?

module ProductsRenderer
  def self.index 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 renderer, since renderers have the benefit of having unambiguously resolvable method names.

I don’t think that’s something people would do a lot, but they still easily could: ProductsRenderer.index(self)

Then how would you call this from a helper method?

Hiccdown methods should live in their own, separate modules. How about they are called ‘renderers’?

module ProductsRenderer
  def self.index vc, # …
    vc.some_helper_method
  end
end

That would be mixing class methods an instance methods in Rails helper modules, which typically only contain instance methods. Not idiomatic Rails usage.

Superseded by #310. This comment was generated automatically.

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:

So instead of

@helper_module.instance_method(@action_name).bind_call(view_context)

I would do

@helper_module.send(@action_name, view_context)

And the parameter list of each Hiccdown method would start accordingly:

module ProductsHelper
  def self.index vc #, …
    vc.some_helper_method
  end

  def some_helper_method
    # …
  end
end

Superseded by #308. This comment was generated automatically.

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:

So instead of

@helper_module.instance_method(@action_name).bind_call(view_context)

I would do

@helper_module.send(@action_name, view_context)

And the parameter list of each Hiccdown method would start accordingly:

module ProductsHelper
  def self.index vc #, …
    # …
  end
end