Some thoughts on sharing behaviour between components using prepend

[thomasbrus]

Hi!

We are in the process of setting up a design system using view_component. I ran into the need to share behaviour between components for consistency & code reuse.

Behaviour shared between all components

It'd be cool if all components accept a :html property that can be used to apply arbitrary html attributes on the root element of the component (think adding an dom id for controller tests or data-targetto hook a component up to a Stimulus controller.

Specific behaviour shared between some components

Some components share the same properties with the same values, such as size: :small | :normal | :large, or :color to pass a color scheme to use, or :icon if the component accepts an icon name, and so on.

Goal is to mix & match, i.e. some component have a :size and :color while another provides :size and :icon as properties.

Implementation

To solve this, I used the following pattern shown below. Thought it might be helpful to share :) (it depends on Ruby 2.7+ and this PR to remove the need for explicit #initialize method).

First add the properties shared between all components to ApplicationComponent and call super(**opts) from child components:

# app/components/application_component.rb
class ApplicationComponent < ViewComponent::Base
  def initialize(html: {})
    @html = html
  end
end

Then extract specific properties into their own modules in app/components/concerns. By using prepend, they can call super in their initialize method and pass the "rest" props (**opts) up to the parent class. This preserves the behaviour of a missing keyword error when a non-existing property is passed to the component.

This is also the place to provide default arguments and perform validation (via raise for example).

# app/components/concerns/with_size.rb
module WithSize
  def initialize(size: :normal, **opts)
    raise ArgumentError, "invalid size" unless DesignSystem::Size.sizes.include?(size)

    @size = size
    super(**opts)
  end
end

# app/components/concerns/with_color.rb
module WithColor
  def initialize(color: :gray, **opts)
    raise ArgumentError, "invalid color" unless DesignSystem::Color.colors.include?(color)
    
    @color = color
    super(**opts)
  end
end

# app/components/concerns/with_icon.rb
module WithIcon
  def initialize(icon: nil, **opts)
    @icon = icon
    super(**opts)
  end
end

Then finally the implementation of the actual components is pretty straight forward:

# app/components/label_component.rb
class LabelComponent < ApplicationComponent
  prepend WithColor
  prepend WithIcon
  prepend WithSize
end

# app/components/icon_component.rb
class IconComponent < ApplicationComponent
  prepend WithSize

  def initialize(name:, **opts)
    @name = name
    super(**opts)
  end

  def pixel_size
    # ... convert @size to pixel size ...
  end
end

And then to use the components with the various properties that are now available:

/ large purple label with custom id
= render LabelComponent.new(size: :large, icon: 'at', color: :purple, html: { id: dom_id(...) }) do
  | [email protected]

/ icon with html class
= render IconComponent.new(size: :small, name: 'checkmark', html: { class: 'float-right' })

Feedback

Would love to hear from others what you think of this pattern. Or what other patterns you found useful to share behaviour between components!

[bdmac]

One thing that came up recently in my use of components which would be made possible by the addition of a root element is for github/github to be able to automatically inject data attrs on the component's root node for testing purposes (e.g. with test_selector) based on the component's class name/module scope. This shared behavior would also allow for the consumer of a generic component to generally always be able to pass in an override for the default data-test-selector.

[thomasbrus]

Interesting!

[simonrand]

@thomasbrus this is looking very similar to something I'm working on at the moment which I posted about previously #341 - I'd see one benefit of the approach I've got as being able to easily constrain what values are allowed for each property - any thoughts/comments are very welcome!

[thomasbrus]

@simonrand

That's neat, I see you're also using Tailwind CSS. Regarding property validation, there are probably a couple of different ways to go about this.. raise in #initialize, ActiveModel validations, or your approach of explicitly defining property values / classnames. (https://github.com/simonrand/view_component_properties)

I'm curious to see where our project will go and if we need a more "heavy" solution than what we have now. For sharing/extracting behaviour, I'm a bit hesitant to introduce too much DSL, rather stick to include/prepend/inheritance because that's usually easier to debug:)

[simonrand]

We're in exactly the same situation, we're still working on this whole concept, it's still not fully there we're still finding ways to improve it, as we do we'll be updating the repo as we go - we'll just have to see where this all ends up!

[being-frank]

I'm in the exact same boat at the exact same time and I was going to ask how to approach this. While my design system does not use Tailwind, things like margins, paddings, colors and font-sizes are "utility based". I was headed down the same path as your gem @simonrand and I'm glad I'm not the only one. I also don't know where all of this will end up, but I'm trying to avoid landing into a corner.

[joelhawksley]

I remain hesitant about having ViewComponent having any opinion on what it outputs beyond HTML safety. Happy to have my mind changed ❤️