Using ViewComponent in all Views

[MatheusRich]

Rails lacks a proper view layer. The separation between view and template is default in many frameworks: Elixir's Phoenix and Hanami are examples.

ViewComponents addresses this issue in a small scale. I wonder if there's any common pattern (or pitfall) in using ViewComponent to render all views (directly from controllers). This would allow separation of concerns that presenters / decorators / helpers currently try to fix.

# app/controllers/users_controller.rb

class UsersController < ApplicationController
  def show
    user = User.find(params[:id])

    render User::Show.new(user: user)
  end
end

# app/views/user/show.rb

class User::Show < ViewComponent::Base
  attr_reader :user

  def initialize(user:)
    @user = user
  end

  private

  def first_name
    @user.name.split.first
  end

  def nickname
    @user.nickname || 'no nickname'
  end

  def profile_pic_url
    @user.profile_pic_url || image_path('default-user-avatar.png')
  end
end

<%# app/views/user/show.html.erb %>

<div>
  <img src=<%= profile_pic_url %> alt="User profile pic">
  <h1><%= first_name %></h1>
  <h2><%= nickname %></h2>
  <%= link_to 'Edit', edit_user_path(user) %>
</div>

Any thoughts on that? Someone already going this route?

[pinzonjulian]

At my company we decided to completely replace rails' view layer with view component about a year ago. The coding style we follow is one of very focused, single-responsibility objects (queries, commands, etc) so this was a natural transition for us. It's still uncharted territory and we haven't set any rules/conventions in stone yet but this is what regularly happens:

Note: this examples use rails 6.0. I'll explain some differences with rails 6.1 below

Controller Actions

# app/controllers/posts_controller.rb

class PostsController < ApplicationController
  def index
    # Posts are injected as a dependency of the component. 
    # We'd like to do this query inside the component but pagination with Pagy
    # has proven to be a bit harder than it seems.

    @posts = Post.all

    # We sometimes inject params as well because some part of the component usually needs them. 
    @component = Posts::IndexComponent.new(posts: @posts, params: params)
  end

  def show
    # In this example, as I don't have to paginate, I'd rather do the query to retrieve the post inside the component
    @component = Posts::ShowComponent.new(params: params)
  end
end

Views

This is super boilerplatey but it's necessary in rails 6.0.x

# app/views/posts_controller/index.html.erb
<%= render @component =>

# app/views/posts_controller/show.html.erb
<%= render @component =>

We've had to render views this way because in rails 6.0 you can't render components from the controller. This was fixed in rails 6.1 where you can call render Posts::IndexComponent.new(...) directly in the controller.

The good

1 object, 1 action is liberating

It allows you to think of views in an object oriented way and frees you up to use as many methods as you want to process your data and create your view. I know this is possible in a controller as well but you end up mixing methods for different actions and the private section of your controller ends up being a mess.

The bad

You don't always need this amount of complexity.

Sometimes I find myself having to write a ton of boilerplate just to render a simple thing in the screen which is in part a problem of...

Not having conventions

If this was a conventional approach where, say, in a generator, all files were created for me, that'd be awesome.

Losing some of rails's nicest magic

I love things that rails does like render @post which goes and looks for the partial using to_partial_path. I think those are beautiful abstractions that I've lost by making this transition.

The future

It's funny you mentioned this just now because a couple of days ago I started a personal project trying to fix the lack of conventions. I've slightly monkeypatched render to go look for components in a conventional way, similar to what rails does for you. I want to write an article about this (my first one I should say!) so I'll post it here once it's done. What I can tell you is that once you wrap your head around the idea of an Action being a first class citizen of the app, it starts to look an awful lot like a controller with a single action... which has one template... essentially a view component supercharged with action pack.

Ok, I won't spoil it anymore. I hope this helps!

[MatheusRich]

Maybe ViewComponent could allow changing render @user to look for a component, rather than a partial. It could start as a monkey patch and get upstreamed layer.

[Jonic]

I'd also like to be able to specify the directory in which a component should attempt to look for its erb template. To use @pinzonjulian's example above, when rendering Posts::IndexComponent.new, I'd like to be able to tell this component to use a template in /app/views/posts/index.html.erb.

Taking this thinking further, my application will contain components that power pages, page-specific ui, site-wide ui, and elements from our pattern library. I'd like to be able to better control the separation of these templates, and also to keep them somewhere other than the /app/components directory (it never felt right the right place to keep templates).

So with my four component types I'd like to be able to specificy the following template locations:

• /app/views/pages/[page_name].html.erb
• /app/ui/[page_name]/[component_name].html.erb
• /app/ui/application/[component_name]/index.html.erb
• /lib/patterns/[component_name]/index.html.erb

This is just an example. I'm not saying this is the best way to organise component templates. I'm just trying to illustrate that having the option to tell a component where its corresponding template file lives might be of some use!

I've had a quick look through the Gem, but there doesn't appear to be an obvious way to specify the location of a component's view. If anyone has any tips on what the monkey-patch would look like for this then I could help put together a PR too, if others think that this might be a useful feature?

[pinzonjulian]

@Jonic View components don't need to necessarily live in the app/components folder. As view components are just objects, they'll be autoloaded by rails as long as they live in any folder inside of app so you can create the best structure that works for you.

Rails doesn't autoload every folder inside app though, it leaves a few out like the app/views folder.

If you have something in the lib folder, you'll need to manually require it wherever you need to use it.

You can definitely create that folder structure without any issues.

[Jonic]

Thanks for your reply :)

I might not have explained myself well enough, but I was wondering if it might be possible to keep just the html.erb template file somewhere that isn't next to the component itself.

To simplify my example from above:

I have an app/pages directory, which contains Components (and that's working fine), but I'd like to keep the .html.erb for a component somewhere else.

In the following example, home_page.rb extends ViewComponent::Base:

Not this:

app/pages/home_page.rb
app/pages/home_page/home_page.html.rb

...and not this:

app/pages/home_page.rb
app/pages/home_page.html.rb

...but THIS:

app/pages/home_page.rb
app/templates/pages/home_page.html.rb

If there was a method I could use in ViewComponent::Base via HomePage that would override the template directory, the component would know where to look for the .html.erb file required to render the component. The current behavior would be the default.

class HomePage < ViewComponent::Base
  template_directory 'app/templates/pages'
end

I shouldn't have focussed my previous example on four different component types - that's very specific to my application, when I should have actually asked something much more generalised to better get my point across :)

[joelhawksley]

@Jonic that's an interesting proposal. I'd be curious to hear why you'd like to have the templates in another directory.

The reason we explicitly require colocation of ViewComponent templates is that they are compiled and executed within the context of the ViewComponent object, and thus behave differently than if they were rendered with the traditional Rails stack.