View components are Github's stab at a more modern front end framework solution built specifically for rails. It focuses on code encapsulation to build reusable and testable UI components called View Components. They're based off of the Presenter Pattern, which addresses bloated views and controllers by "creating a class representation of the state of the view". What's nice about VC's is that they allow for logic that would typically live in the controller or view to live within them. Github describes these as ruby objects that output HTML, so when thinking of rendering a VC, think of it as instantiating an instance of that Component Class and accessing its methods. An important note to remember here is that a large portion of what will be covered here can also be accomplished using rails partials. The main benefit is that you can abstract away the large majority of a view's logic into a class, reducing clutter in your .erb files.
Encapsulation
View Components provide encapsulated packages for everything your view needs, separating it from your controller and its logic. In other words, parameters are passed into View Components, but will not bleed in automatically from those set in the controller. This provides a clear source for the information, and removes the guesswork that comes with figuring out what is set where. Not to mention testing this way becomes MUCH nicer.
Explicit Initializer
View components implement a standard Ruby initializer that gives a more explicit requirement on what is needed to render. In other words, think of if I were to show you a file for a partial requiring 6 different variables. You can imagine how it can take some time to identify them all. View Components (at their base level) feature a .rb class file and a .html.erb template file. The class file defines the Ruby initializer with all parameters required for it to render, making it much easier to identify what parameters need to be passed in.
Speed
Github also points out that their View Components are ~10x faster than partials according to their benchmarks. This is particularly the case when in your production environments as Rails caches classes (or in other words VCs) rather than compiling the every use. The trick here is that class caching is disabled by default in development, but enabled in prod →
View component is significantly slower than partials · Issue #345 · github/view_component
One of the main reasons why you'd create a view component is to be able to reuse it. An easy example is a card where with libraries such as Bootstrap it's pretty simple to reuse the same classes to achieve the same look for each one across your site. The complication arises when there's custom logic, such as permissions and javascript that apply to these cards. VCs help here by encapsulating the logic in the class definition, and packaging asset files along with it. So in this scenario, we would create a card component that would take in a theme and some text. The class file can handle custom rendering, routing and more to alleviate the view. For example, this: view.html.erb
<div class="card">
<div class="card-body">
<% if user_can_do_this %>
<h5 class="card-title">Show this text!</h5>
<% elsif user_can_do_that %>
<h5 class="card-title">Show that text!</h5>
<% end %>
</div>
</div>
And you can imagine that you would still have to put this logic in a card partial or render the partial within each if-block which still keeps too much logic in the view. With VCs, this can be changed to:
<%= render(CardComponent.new(user: user)%>
class CardComponent < ViewComponent::Base
def initialize(:user)
if user.can_do_this
@title = "Show this text!"
elsif user.can_do_that
@title = "Show that text!"
end
end
end
<div class="card">
<div class="card-body">
<h5 class="card-title"><%= @title %></h5>
</div>
</div>
Now, anytime you need to render that card just pass in the user and forget the rest. You can also imagine how much easier it is to test the CardComponent class and view separately, than it would be to test it all mushed together.
Collections