Hiccdown Development Notes

  Dennis Hackethal posted criticism #4333.

When an empty block is passed to render, it results in an empty tag '<>'

  Dennis Hackethal posted idea #4332.

Some Reagent-like way to make things reactive using proc as first element? And then the server keeps track of which procs have been rendered, which items have changed, and re-renders that part of the template in a turbo stream?

  Dennis Hackethal posted idea #4331.

Use frame layout for turbo frame requests? https://discuss.rubyonrails.org/t/the-right-way-to-override-render-method/84765/2

  Dennis Hackethal posted criticism #4330.

Redirects result in two additional requests, the first of which is a turbo-stream request that renders nothing, thus (presumably) prompting the browser to make another request for the same resource.

This? https://stackoverflow.com/a/74071278

  Dennis Hackethal posted idea #4329.

Is there a way to teach user-built helpers how to process Hiccdown? Or maybe intercepting capture already took care of this?

  Dennis Hackethal posted idea #4328.

Could the application layout live in ApplicationHelper#layout?

  Dennis Hackethal started a bounty for idea #4327 worth USD 150.00.
  Dennis Hackethal posted idea #4327.

Hiccdown is bug-free.

  Dennis Hackethal archived idea #333 along with any revisions.
  Dennis Hackethal archived idea #303 along with any revisions.
  Dennis Hackethal archived idea #300 along with any revisions.
  Dennis Hackethal archived idea #313 along with any revisions.
  Dennis Hackethal posted criticism #1984.

Hiccdown should have support for ids and class names in the tag symbol. Like Hiccup.

ruby
[:'div#my-id.my-class.another-class']

# => <div id="my-id" class="my-class another-class"></div>

It should also allow mixing:

ruby
[:'div#my-id.my-class.another-class', {id: 'override', class: 'additive'}]

# => <div id="override" class="my-class another-class additive"></div>

In other words, the id from the hash would override the id from the symbol, and the class from the hash would be added to the classes from the symbol.

  Dennis Hackethal revised idea #330 and marked it as a criticism.

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

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:

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 classes. How about they are called ‘displays’?

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:

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
  Dennis Hackethal revised idea #303 and marked it as a criticism.

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

ruby
ProductsHelper.index

StoresHelper.index

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

ruby
ProductsHelper.index

StoresHelper.index
  Dennis Hackethal revised idea #302 and marked it as a criticism.

Hiccdown methods should live in Rails helpers as instance methods.

Hiccdown methods should live in Rails helpers as instance methods.

  Dennis Hackethal posted criticism #859.

Could the errors around layouts be related to this?

  Dennis Hackethal addressed criticism #331.

Not as of #330, they couldn’t.

#331​·​Dennis HackethalOP, over 1 year ago

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

  Dennis Hackethal revised criticism #334 and unmarked it as a criticism.

Accidentally marked as a criticism

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.

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.

  Dennis Hackethal criticized idea #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.

#333​·​Dennis HackethalOP, over 1 year ago

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.

  Dennis Hackethal posted idea #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.

  Dennis Hackethal criticized idea #303.

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

ruby
ProductsHelper.index

StoresHelper.index
#303​·​Dennis HackethalOP, over 1 year ago

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

  Dennis Hackethal addressed criticism #315.

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

#315​·​Dennis HackethalOP, over 1 year ago

Not as of #330, they couldn’t.

  Dennis Hackethal revised idea #325.

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

ruby
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.

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

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:

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
  Dennis Hackethal addressed criticism #328.

They are: vc.instance_variable_get(:@foo)

#328​·​Dennis HackethalOP, over 1 year ago

That’s way too verbose.