Hiccdown Development Notes

Dennis Hackethal started this discussion over 1 year ago.

Active ideas·Search·Activity

Notes about developing the Ruby gem Hiccdown.

Log in or sign up to participate in this discussion.

With an account, you can revise, criticize, and comment on ideas, and submit new ideas.

New activity, such as comments or revisions, ‘revives’ archived ideas.

Discussions can branch out indefinitely. You may need to scroll sideways.

Dennis HackethalOP·#1978

3rd of 3 versions

Hiccdown methods should live in Rails helpers as instance methods.

CriticismCriticized1Archived

Dennis HackethalOP·#301

That isn’t a good idea because Hiccdown methods often share the same conventional names (index, show, etc), which can and does lead to conflict.

Criticism of #1978Archived

Dennis HackethalOP·#1980

2nd of 2 versions

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

1
2
ruby
ProductsHelper.index
StoresHelper.index

CriticismCriticized2Archived

Dennis HackethalOP·#312

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

Criticism of #1980Archived

Dennis HackethalOP·#332

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

Criticism of #1980Archived

Dennis HackethalOP·#305

2nd of 2 versions

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.

Criticism of #1980Criticized1Archived

Dennis HackethalOP·#310

3rd of 3 versions

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

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

I would do

1
ruby
@helper_module.send(@action_name, view_context)

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

1
2
3
4
5
6
7
8
9
ruby
module ProductsHelper
  def self.index vc #, …
    vc.some_helper_method
  end

  def some_helper_method
    # …
  end
end

Criticism of #305Archived

Dennis HackethalOP·#1982

5th of 5 versions

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

1
2
3
4
5
ruby
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:

1
2
3
4
5
6
7
8
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:

1
2
3
4
5
ruby
class ProductsDisplay
  def index vc, # …
    vc.some_helper_method(@products)
  end
end

CriticismCriticized1Archived

Dennis HackethalOP·#326

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

Criticism of #1982Archived

Dennis HackethalOP·#317

2nd of 2 versions

Then how would you call index from a helper method?

Criticism of #1982Criticized1Archived

Dennis HackethalOP·#315

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

Criticism of #317Archived

Dennis HackethalOP·#321

Test this!

Criticism of #315Criticized1Archived

Dennis HackethalOP·#323

2nd of 2 versions

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

Criticism of #321Archived

Dennis HackethalOP·#331

Not as of #330, they couldn’t.

Criticism of #315Criticized1Archived

Dennis HackethalOP·#341

It doesn’t really matter. This would be like calling a controller action from a helper method. Not something people do.

Criticism of #331Archived

Dennis HackethalOP·#333

Having explored three different ideas, I believe #302 – having regular helper methods to render Hiccdown structures – is the best.

The idea is not without its flaws, but having to qualify a method name by, say, calling it idea_form instead of form is still better than manually having to pass the view context around all the time and not being able to trivially access instance variables.

So I’ll stick with #302 for now, which is the status quo already.

Archived

Dennis HackethalOP·#335

2nd of 2 versions

I think the thing I’m really fighting here is Rails being object-oriented. Which I can’t do anything about.

Not sure the Rails team realizes how much OOP reduces the extensibility of Rails.

Archived