A framework for creating reusable, testable & encapsulated view components, built to integrate seamlessly with Ruby on Rails.
What’s a ViewComponent?
Think of ViewComponents as an evolution of the presenter pattern, inspired by React. A ViewComponent is a Ruby object and template:
# app/components/message_component.rb class MessageComponent < ViewComponent::Base def initialize(name:) @name = name end end
<%# app/components/message_component.html.erb %> <h1>Hello, <%= @name %>!</h1>
Which is instantiated and passed to Rails’
<%# app/views/demo/index.html.erb %> <%= render(MessageComponent.new(name: "World")) %>
Why use ViewComponents?
ViewComponents work best for templates that are reused or benefit from being tested directly. Partials and templates with significant amounts of embedded Ruby often make good ViewComponents.
Rails applications often scatter view-related logic across models, controllers, and helpers, diluting their intended responsibilities. ViewComponents consolidate the logic needed for a template into a single class, resulting in a cohesive object that is easy to understand.
ViewComponent methods are implemented within the scope of the template, encapsulating them in proper object-oriented fashion. This cohesion is especially evident when multiple methods are needed for a single view.
ViewComponent was designed with the intention that all components should be unit tested. In the GitHub codebase, ViewComponent unit tests are over 100x faster than similar controller tests.
With ViewComponent, integration tests can be reserved for end-to-end assertions, with permutations covered at the unit level.
For example, to test the
class MessageComponentTest < GitHub::TestCase include ViewComponent::TestHelpers test "renders message" do render_inline(MessageComponent.new(name: "World")) assert_selector "h1", text: "Hello, World!" end end
ViewComponent unit tests leverage the Capybara matchers library, allowing for complex assertions traditionally reserved for controller and browser tests.
Traditional Rails templates have an implicit interface, making it hard to reason about their dependencies. This can lead to subtle bugs when rendering the same template in different contexts.
ViewComponents use a standard Ruby initializer that clearly defines what’s needed to render, making reuse easier and safer than partials.
Based on several benchmarks, ViewComponents are ~10x faster than partials in real-world use-cases.
The primary optimization is pre-compiling all ViewComponent templates at application boot, instead of at runtime like traditional Rails views.
For example, the
MessageComponent template is compiled onto the Ruby object like so:
# app/components/message_component.rb class MessageComponent < ViewComponent::Base def initialize(name:) @name = name end def call @output_buffer.safe_append='<h1>Hello, '.freeze @output_buffer.append=( @name ) @output_buffer.safe_append='!</h1>'.freeze @output_buffer.to_s end end
Template code often fails basic Ruby standards: long methods, deep conditional nesting, and mystery guests abound.
ViewComponents are Ruby objects, making it easy to follow (and enforce) code quality standards.
ViewComponent is built by over a hundred members of the community, including:
Who uses ViewComponent?
- Bearer (70+ components)
- City of Paris
- G2 (200+ components)
- GitHub (900+ components used 15k+ times)
- Mission Met Center
- Mon Ami
- Nikola Motor (50+ components and counting)
- openSUSE Open Build Service
- Project Blacklight
- Spina CMS
- Startup Jobs
Using ViewComponent? Send a pull request to update this list! You can also check out how various projects use ViewComponent.