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.

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…

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.

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

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

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.

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.

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

Hiccdown methods should live in Rails helpers as class methods. That way, the problem described in #302 is solved – methods can be referenced unambiguously:

ProductsHelper.index
StoresHelper.index