Why ViewComponents don't have better syntactic sugar? Like a "component" helper

[collimarco]

Compared to Rails helpers, I find the syntax of ViewComponents quite verbose...

render NavComponent.new

This would be much easier to read/write:

component :nav

Are there any good reasons for not using this more succinct naming?

I also found articles like this that suggest to create your own helper, but I wonder if it's a good idea or not... Why ViewComponents don't provide something similar out of the box?

https://dev.to/scottbarrow/rails-viewcomponent-helper-ibn

[collimarco]

Or maybe even something shorter like c :nav (abbreviation of component) or x :nav (which reminds custom elements <x-nav></x-nav>)

[collimarco]

Here's another interesting article:

https://evilmartians.com/chronicles/viewcomponent-in-the-wild-supercharging-your-components

And another, different solution, to the same problem:

https://github.com/x-govuk/govuk-components/blob/main/app/helpers/govuk_components_helper.rb

I think that many people would love a standard solution, in order to ensure a consistent naming convention across all Rails applications.

[collimarco]

Here's another solution:

https://answers.abstractbrain.com/using-rails-helpers-x-component-for-rendering-viewcomponents

[joelhawksley]

@collimarco while this isn't the only reason, one cause for hesitation around introducing such a helper is that it likely would lead to ambiguous references to components.

For example, if I had a User::Avatar component and an Organization::Avatar component, which one would component :avatar render? I know that Rails supports ambiguous references to view files (like render :show and implicit rendering in controllers), but we do not allow this functionality in GitHub Rails applications: https://github.com/github/rubocop-github/blob/main/lib/rubocop/cop/github/rails_controller_render_literal.rb#L12.

Ambiguous references also make it difficult to pre-compiles Rails templates and components, leaving several avenues for performance optimization off the table.

I'd be happy to discuss this further, but figured it'd be helpful to share where at least some of my hesitation lies.

[collimarco]

Thanks for the reply.

For the namespace consider that we can use the same solution used by Rails for namespaced routes: add a namespace prefix. For example, x_primer_avatar would render Primer::AvatarComponent.

Does this solve your concern?

[Spone]

How do you distinguish Primer:: AvatarComponent from PrimerAvatarComponent if both happen to exist?

[collimarco]

@Spone You have the exact same issue with Rails route helpers. Their solution is to raise an exception in case of conflict (can be determined immediately when rails is loading).

Otherwise, you could use namespace with BEM-style notation (e.g. x_primer__avatar).

Personally I prefer the first solution.

[digerata]

It would be interesting to take a poll on how users of ViewComponent are using it in the wild. With syntactic sugar or without?

I suspect the vast majority do not type render ComponentName.new(all_my_options) but use something nicer.

We are in the process of adding this to an existing project and using it for the first time. There's at least a half a dozen ways I've found to make life easier on this subject. Wouldn't it be nicer to just standardize on one?

[joelhawksley]

I generally agree with @reeganviljoen's answer here too. I think the current API is consistent with rendering view and partials, making it easier for folks to transition to using ViewComponent and to use both ViewComponents and views/partials in a single application.

[collimarco]

Helpers offer a much cleaner reading experience and faster typing. They also look like custom html tags and remind the syntax of Rails helpers (link_to, image_tag, etc.)

[digerata]

Something occurred to me over the weekend... Why does render ComponentName.new(all_my_options) feel so aesthetically wrong to me? I think it's because of the object creation... "Class.new".

In a stock standard Rails app, we never use class creation directly in the views. So with the following:

<%= render partial: "filename", locals: {} %>

<%= render @model_object %>

<%= render MainMenuComponent.new(default_options) %>

"🎶One of these is not like the other 🎶" (apologies to those of you that did not grow up with Sesame Street)

While this may adhere to standard Rails APIs, it doesn't feel the same as the other calls. Off the top of my head, I can't think of any place where we use a capital letter in our ERB/HAML source code. I may be wrong there, but I think the general idea is accurate.

When we talk about API here, do we mean simply using render?

If so, render isn't the only way to put HTML in the response. If you are using partials (who isn't?), then <%= helper_method_that_spits_out_html %> is very common and isn't adhering to any API.

I'm not trying to change minds, I just thought I would chime in on this thread that this viewpoint is something more than a few people share. If that many people are making these types of changes when implementing ViewComponent, maybe another option could be considered?

[joelhawksley]

When we talk about API here, do we mean simply using render?

Yes. While there are other ways of rendering views in Rails, render remains the prominent API convention. It's also used for Phlex, another renderable object library.

I could see having such a syntactic sugar helper sit in a gem, maybe as render_component_helper?

It's also worth mentioning that Rails is considering some changes to the render API, but I believe the class reference would remain: rails/rails#50623.

[digerata]

@joelhawksley Thanks for the tip there, good to know.

I do think the change to render is a step in the right direction, for sure. This is nicer:

render(MyComponent, name: "Fox Mulder")

We settled on the smallest surface area we could find by adding a helper method to our ApplicationHelper:

 def component(name, *args, **kwargs, &block)
    component = name.to_s.camelize.constantize::Component
    render(component.new(*args, **kwargs), &block)
  end

to have syntax like:

= component "myexample", name: "Fox Mulder"

Which is not that far off and suddenly it starts to feel like I'm inside a bike shed... 😄

Thanks for the comments!