Adding a conventional ID to view components

[pinzonjulian]

I've been writing a lot of components lately that need a unique ID and I'd love to have a simple way to add it, similar to what rails does with dom_id(instance)

I've played with the following:

class DogComponent < ViewComponent::Base
  include ActiveModel::Naming # included to use `model_name.singular`

  def initialize(dog: )
    @dog = dog
  end

  def component_dom_id
    component_name = self.class.model_name.singular
    dom_id(main_instance, component_name.to_sym) # would return something like dog_component_dog_33442
  end

  def main_instance
    @dog
  end
end

<%= content_tag(:div, id: component_dom_id) do %> 
  # ...

The method main_instance could even pave the way for things like caching 🤔

[joelhawksley]

@pinzonjulian thanks for taking the time to file this issue!

This is interesting! I'd be curious to have you add this to your ApplicationComponent and use it across your application to see how it goes.

I'm not sure that we can assume that ViewComponents represent a single record, or rather, any single entity, that has a unique identifier.

[pinzonjulian]

I've found two types of components in my app

1. General, very reusable components. For example.. an AvatarComponent which uses initials and a URL.
2. Specific ones that map 1-1 to a model (either an ActiveRecord model or a virtual model that uses ActiveModel::Model) and that are part of pages with a fair bit of interactivity.

For the general ones, I agree with you that it's impossible to assume they represent a single record/entity. And it probably isn't necessary either.

However for the specific ones I've needed to add this to do some dom manipulations. I could probably write more/better stimulus controllers to avoid having to use dom ids but there's been a couple of times where it's just easier to target something by it's ID rather than using stimulus' targets.

It something I sort of expected the view component to have coming for very traditional rails where there's a strong assumption that an instance of a model maps directly to a partial which is a similar assumption that caching does.

[dlegr250]

I do something similar to this, where I need to dynamically update components on a given page using JS. I did 2 things:

1. Added #dom_id method to ApplicationRecord so that every model object can reference it outside of views. This is just for convenience, and I didn't have a problem with building the "view" method into the model record itself. Some may hold that this is violating separation of concerns.
2. Added #data_attribute_value method to ApplicationComponent to easily reference components.

I didn't want to use ID attribute because I can have multiple instances on a page.

# app/models/application_record.rb

# ie, "Namespaced::User.find(123)" => "namespaced_user_123"
def dom_id
  "#{model_name.to_s.underscore}_#{id}"
end

# app/components/application_component.rb

def data_attribute_value(dom_id)
  # Module::NameOfComponent => "name_of_component"
  component_name = self.class.name.demodulize.underscore

  "#{dom_id}.#{component_name}"
end

When I create a component it has a data-attribute="<%= data_attribute_value(record.dom_id) %>" attribute so I can easily reference it via JS.

# update.js.erb for some action (using jQuery for simplicity)

$("[data-attribute~='<%= @transaction_record.dom_id %>.stage_button_component']").replaceWith("<%=j render(TransactionRecords::StageButtonComponent.new(transaction_record: @transaction_record)) %>")

This approach allows me to have multiple instances of the same component on the page and update them all dynamically. It would be nice to have a convention for the view_component gem for something like this.

I did a quick inspect page on Github's site and it doesn't seem that Github itself is using any sort of per-component identifier, meaning you would have to wrap a larger partial or do page DOM-diffing I guess to dynamically update pieces of the page with view components?

The above approach has worked well for me, and enables me to know what code maps to that component because of the naming convention I added.

[benkoshy]

I have exactly the same use case.

Use Case

<%= turbo_stream.update WidgetButtonComponent.new(widget: widget_record) do  %>        
            ... etc.
<% end %>

Proposed API

vanilla rails implementation:

widget = WidgetButtonComponent.new(widget: Widget.find(32) ) 

# ids:
dom_id( widget) 
# => "widget_button_component_32"

# new widget
dom_id( WidgetButtonComponent.new(  ) )
# => "new_widget_button_component"

# Classes:
dom_class( widget)
# => "widget_button_component"

dom_class( WidgetButtonComponent)
# => "widget_button_component"

Why?

Just as with dom_id(record) we should not worry about handling dom_id logic in standard views - that can all be encapsulated.

<-- i would want to avoid this to work out dom_ids -->
<div  id="<%  if new_widget ? "new_widget_button_component" : 
              "widget_#{widget.id} " %>"  > # no need for this logic here
</div>

... but why bother?

Convention! Saves people from thinking, makes it faster. Thinking is exhausting. And most of us are kinda doing the same thing. And if we should want something different - then we can simply override it. Which is what we'll be doing anyway.

Is it a bad idea?

Will such an approach be a bad idea for the community?

[benkoshy]

Code Sample

# Some view:
# puts @quote.id 
# => 73
<div>
     <%= render(Quotes::QuoteStateComponent.new(quote: quote))  %>
</div>

# renders:
# <div id="quote_state_component_73"> .... 

Let's update the component via a turbo_stream:

# update.turbo_stream.erb
<%= turbo_stream.replace Quotes::QuoteStateComponent.new(quote: @quote) do  %>
         ...
<% end %>

Notice we don't have to target it with a dom_id? But how?

All you need is a: model_name and to_key, added to your component, and Rails will take care of the rest - see here: https://api.rubyonrails.org/classes/ActionView/RecordIdentifier.html#method-i-record_key_for_dom_id

# app/components/quotes/quote_state_component.rb
# app/components/quotes/quote_state_component.html.erb


# frozen_string_literal: true
class Quotes::QuoteStateComponent < ViewComponent::Base
  
  def initialize(quote:)
    @quote = quote
  end

  def model_name
    OpenStruct.new param_key: 'quote_state_component'
  end

  def to_key
    [@quote.id]
  end  
end

Boom! In one fell swoop, I can update via stream, all my components, and have the dom ids encapsulated.

I feel that the model_name can and should be extracted into the ViewComponent library, if it already doesn't exist. my two cents.

[joelhawksley]

While I think this is a good idea, I don't feel ViewComponent should be responsible for what is rendered. If there are framework hooks/feature we can add to make this functionality easier to implement elsewhere, I'd be more than happy to consider implementing such changes ❤️