Component and View Colocation

[BlakeWilliams]

Currently, components live in a dedicated app/components directory. This has worked well so far, but we'd like to explore a more unified approach.

This isn't set in stone, but the goals would be to:

• Allow components to be defined in app/views
• Enable render "users/show", user: current_user to render a component instead of explicitly referring to the component class. e.g. This would be equivalent to render Users::Show.new(user: current_user)
• Remove the Component suffix from components so their names have a 1-to-1 mapping to view directories. e.g. app/views/users/user.rb would map to class Users::User < ViewComponent::Base

A more complete example may look like:

# app/controllers/users_controller.rb
class UsersController < ApplicationController
  def show
    user = User.find(params[:id])
    render :show, user: user
  end
end

# app/views/users/show.rb
class Users::Show < ViewComponent::Base
  def initialize(user:)
    @user = user
  end
end

<%# app/views/users/show.html.erb %>
<div>
  <h1><%= @user.name %>'s page!</h1>
   <%= render "users/profile_content", user: user # will render the app/views/users/profile_content.rb component %>
</div>

part of https://github.com/github/view_component/issues/617

[MatheusRich]

Related: https://github.com/github/view_component/discussions/588

[BlakeWilliams]

I've spiked this out a bit here: https://github.com/BlakeWilliams/view_component-rails-test/pull/1/files (PR's showing off other ideas or approaches are welcome)

Some take-aways:

• _ prefixed file names for use as partials doesn't feel like the correct approach for components.
• Using strings, e.g. render "users/profile, user: user" instead of render Users::Profile.new(user) has some limitations, like requiring that component arguments are keyword arguments.
  • How would render User::Profile.new(user) translate to render "user/profile? The component would be required to change the initializer from def initialize(user) to def initialize(user:).
• Implicit controller renders may be tricky or impractical.

I think the flexibility of view components (e.g. user defined initializers) may make it more challenging to make them work with Rails as seamlessly as we'd like, but I'll keep experimenting with it.

[choilive]

@BlakeWilliams I actually prefer the explicit object instantiation over using strings. Makes it easier to refactor and also makes it clearer that it is a "component" and not a partial. Would be OK with being able to use both ways though as a matter of user preference.

At the moment I feel like trying to unify view components with the existing rails approach to views seems like it would be a bit inconsistent . View_component encourages a more django-like "views and templates" approach that doesn't seem like it would mesh well. Perhaps I just need to play around more with it and see how it would work in practice.

[boardfish]

Just found out about this issue while I've been looking around.

Some observations here:

• I'm trying to do something similar, but all the 'view' ViewComponents are currently under a View namespace right now. I wonder if we should promote using this namespace so that we don't pollute the top-level object namespace. Even if we don't do that, it'd be good for the lookup to support a default namespace.
• I don't think it's a problem that views would need to use keyword arguments. I'm using Active Model with ViewComponent, so that's preferable in my case, but I can understand there may be folks who are initializing in other ways. In the more general case, we already mandate keyword params for rendering with_collection, so I can't imagine it's too much of a problem.
• Implicit controller renders could be possible if the controller has some kind of object that we assign to and then pass to the component, e.g.:

# app/controllers/some_controller.rb
def index
  assigns.posts = Post.all
  # Behind the scenes, the controller will do this:
  # render Index.new, **assigns
end

Effectively, we'd be emulating the idea that you build up instance variables in the controller and pass them to the view, but we'd instead be doing this through assigns so that anything passed to the view (component) is still contained to that component.

[boardfish]

1412 brought this to my attention again. A couple of quick draft thoughts:

• It would be good to maintain compatibility with ActionView, for a few reasons:
  • It might take folks a good while to encapsulate their views
  • Some folks might not even want to encapsulate all of their views for various reasons – developer friction, perhaps only using one or two helpers in a view, etc. Maybe the migration path looks something like this:
    1. User has an ActionView template
    2. User adds an associated class in the correct place, inheriting ViewComponent::Base and including something that makes sure helpers are still available
    3. User overrides helpers by adding methods on the component class, and replaces controller instance variables with variables on the component class
    4. User removes the include once they're through with the migration
• We may want to provide guidance for handing down things that might have been considered globally before from the controller to the view – things like the current user, tenant (for multitenanted apps), current time, etc.. These are the kinds of things that it helps to have available to us globally and might make a genuine use case for helpers, but it's also good to have visibility over them so that they can be mocked or stubbed in tests
• We could do with a codemod/RuboCop autocorrect for rewriting view specs as component specs

[Spone]

Relevant wizardry using Phlex: https://fly.io/ruby-dispatch/component-driven-development-on-rails-with-phlex/ I'm posting it here, since it might give some ideas on the above points.

[bradgessler]

So awesome to see this come to life!

[boardfish]

Ditto that! It would be amazing to use ViewComponent as a view and view model layer in Rails 🎉

[joelhawksley]

@bradgessler @joeldrapper giving dhh's closing of the Rails PR, what do you think about writing a shared gem for implicit renderable rendering that both ViewComponent and Phlex could share?

[joeldrapper]

Yeah, that makes sense to me. Phlex-Rails could depend on that gem.

[joelhawksley]

@joeldrapper great. Want to pick a name? rails-implicit-renderable-rendering?

[reeganviljoen]

@joeldrapper @joelhawksley I really liked this idea, and just put together some code here, mind taking a look https://github.com/reeganviljoen/render_kit