Concerns to help managing View Component attributes
This Gem helps the management of attributes received by View Components (or props, options, however you name them). It offers a set of concerns to mix into your components to:
You can buy in as much or as little of this as you want by picking the concerns you include, it’s up to you.
Pick and chose the concern to include in your components to give them more or less power
WithAttributes: Declare expected attributesInclude the WithAttributes concern to let your component declare the attributes it expects with the same attribute API as ActiveModel (a similar take as view_component-contrib’s use of dry-initializer).
class MyComponent < ViewComponent::Base
include ViewComponentAttributes::WithAttributes
attribute :some_attribute
attribute :attribute_with_default, default: 5
# If you need to compute a default based on other attributes
# you can override the getter and use ActiveModel's `attribute`
# method to read any value provided to the component
attribute :attribute_with_computed_default
def attribute_with_computed_default
attribute(:attribute_with_computed_default) || do_some_computation
end
end
WithUnknownAttributes: Collect unknown attributes for later useBy default ActiveModel will throw if you use unknown attributes during initialization. This makes models safer, but when it comes to the view, you often need to add attributes that shouldn’t be the responsibility of the component itself:
classes because of where the component is rendered, or an id to be referenced by aria-labelledby or aria-controls for accessibility…Include the WithUnknownAttributes concern to avoid an error being thrown and the extra attributes made available through the unknown_attributes method.
Includes WithAttribute
class MyComponent < ViewComponent::Base
include ViewComponentAttributes::WithUnknownAttributes
end
component = MyComponent.new(class:'some-class', id: 'some-id')
component.unknown_attributes # {:class=>"some-class", :id=>"some-id"}
WithRoot and WithRootAttributes: Declare a component’s root element and manage its attributesMost components have their content wrapped by a single root element or sub-component. WithRoot and WithRootAttributes help you define which element or component to use, and combine attributes from different places in a standardised way: declarative defaults (that can be computed), component’s template and component’s initialization.
They can each be used independently, but work best together:
class MyComponent < ViewComponent::Base
# Needs to be first to ensure its `root_attributes` method
# gets overriden as necessary by that of `WithRootAttributes`
include ViewComponentAttributes::WithRoot
include WithComponentAttributes::WithRootAttributes
end
WithRoot provides some help for declaring and rendering the component’s root element or component.
From the template or the component’s call method, the root instance method renders the root of the component.
```erb
<%# my_component.html.erb %>
<%= root(:article, class: "a-class", id: "an-id") do %>
<%# Inside of the component gets rendered here %>
<% end %>
```
The element or component’s class to render can be passed as first positional parameters: a class will be treated as a component, anything else sent to the tag helper.
If you don’t provide any, whichever you provided using the root class method. This can help keep code related to each other in the same place rather than split across class and template. Default is a <div>, but please do take some time to use elements with built-in semantics to give your users the best experience).
```rb
class MyComponent < ViewComponent::Base
root AnotherComponent
end
```
That element or component will be rendered with the provided attributes and the block containing what’s inside it.
Why not plainly set the element in the template (or call)? Using the root method sets you up for a consitent way to make computations for the rendering ot component’s root:
picking the element or component of the root with the root_type method when none is provided in the template. For example, this list component can switch its semantics based on an ordered attribute:
class ListComponent < ViewComponent::Base
include ViewComponentAttributes::WithAttributes
include ViewComponentAttributes::WithRoot
attribute :ordered
def root_type(template_root)
if (ordered)
:ol
else
:ul
end
end
def call
root {content}
end
end
computing the attributes of that root element/component, with the root_attributes method, potentially merging them from different origins.
That’s what the WithRootAttributes concern takes advantage of to work its wonders.
WithRoot provides some structure, but is really mostly a setup for WithRootAttribute. This concern is responsible for mixing attributes coming from different part of the components:
root_attributes class method (either as a hash, or a block if they require computations)root method (or the root_attributes instance method if you need to compute root attributes for a helper like link_to or form_for)root_attributes attributes, as well as all the unknown_attributes gathered by the WithUnknownAttributes concernclass PostComponent
include WithRoot
include WithRootAttributes
attribute :heading
# At class-level, the root attributes can take
# various shape:
# A static set of attributes...
root_attributes({class: 'a-class'})
#
# ...or a block, when computations are needed.
#
# That block can return a hash...
root_attributes do
{
class: compute_the_class
}
end
#
# ... or an array of hashes, allowing to separate different sets of attributes
#
root_attributes do
[
{
class: compute_the_class
},
attributes_for_responsibility_a
attributes_for_responsibility_b
]
end
def attributes_for_responsibility_a
# ...
end
def attributes_for_responsibility_b
# ...
end
end
<%#
These extra attributes will be merged with the defaults,
allowing them to stay grouped in the same file for easier understanding
%>
<%= root(:article, class: 'blog-article') do %>
<h1 class="blog-article__heading"><%= heading %></h1>
<div class="blog-article__body">
<%= content %>
</div>
<% end %>
<%#
Finally, attributes from instanciation will get merged in as well,
allowing to set extra attributes based on:
- where the component is rendered,
- what data it's rendering
- or anything else it's not responsible for.
In case of collision of a root_attribute with one of the component,
you can use the `root_attributes` attribute to make sure of which is which.
%>
<%= render PostComponent.new(
heading: post.title,
id: dom_id(post),
class: 'post-list__post'
) do %>
<%= post.content %>
<% end %>
WithContextAttributes: Setting temporary default attributesSometimes you have a GrandParentComponent, that renders a ParentComponent, that then renders a ChildComponent, which finally renders a GrandChildComponent. It’s all nice… until in a specific scenario that GrandChildComponent needs an extra attribute, for that one time only.
Sure the GrandParentComponent could take it, pass it down, and so could the ParentComponent and the ChildComponent… until it reaches the GrandChildComponent. That’s one more responsibility for them, which is not ideal. And after all, it’s all the GrandChildComponent fault if that needs to happen so best it be the one handling it.
That’s what the WithContextAttributes mixin handles. It adds a with_attributes class method to the GrandChildComponent to temporarily set defaults:
<% GrandChildComponent.with_attributes('data-accordion-target': 'content') do %>
<%#
# Inside this block, new instances of `GrandChildComponent` will receive
# the `data-accordion-target` attribute.
%>
<%= render GrandParentComponent.new(...) %>
<% end %>
<%#
Back out of the block, new instances won't have the attribute,
it's back to normal
%>
Add these lines to your application’s Gemfile
# Ideally replace the `branch: "main"` with a commit reference (`ref: COMMIT_HASH`)
# https://bundler.io/guides/git.html
gem "merge_attributes", github: "Amba-Health/merge_attributes", branch: "main"
gem "view_component_attributes", github: "Amba-Health/view_component_attributes", branch: "main"
Add this line to your application’s Gemfile:
gem 'view_component_attributes'
And then execute:
bundle
Or install it yourself as:
gem install view_component_attributes
After checking out the repo, run bin/setup to install dependencies. Then, run rake spec to run the tests. You can also run bin/console for an interactive prompt that will allow you to experiment.
To install this gem onto your local machine, run bundle exec rake install. To release a new version, update the version number in version.rb, and then run bundle exec rake release, which will create a git tag for the version, push git commits and tags, and push the .gem file to rubygems.org.
Bug reports and pull requests are welcome on GitHub at https://github.com/[USERNAME]/view_component_attributes. This project is intended to be a safe, welcoming space for collaboration, and contributors are expected to adhere to the Contributor Covenant code of conduct.
The gem is available as open source under the terms of the MIT License.
Everyone interacting in the ViewComponentAttributes project’s codebases, issue trackers, chat rooms and mailing lists is expected to follow the code of conduct.