Renderring components automagically

[pinzonjulian]

Hey @joeldrapper!

I've been thinking of a developer experience addition for phlex-rails (and possibly ViewComponent) that would make it feel a bit closer to what you do in regular Rails.

I personally love that templates are rendered without me having to think about it. Yes, globally available instance variables can come and bite you but the general idea... the general feeling of it being automagical is just amazing.

Do you think we could achieve something similar with class based views?

I imagine something like:

class PostsController < ApplicationController
  def index
    posts = Post.all
    render locals: { posts: Post.all } # Renders Posts::IndexView based on the controller#action pair.
  end
end

The call to render locals: { ... } could go through a process of inference where it looks for every possibility: template, phlox-view, view-component etc.

Rails probably already does something similar when inferring the template extension based on the request format.

What do you think?

[joeldrapper]

Yes, if you name your views consistently, you could definitely infer them from the controller/action.

I wonder if defining a new method that delegates the arguments to the default view would be better than overloading render. Here's an example method that seems to work with the recommended view naming in Phlex.

def render_default(...)
  view = Module.const_get("#{self.class.name.delete_suffix('Controller')}::#{action_name.classify}View")
  render view.new(...)
end

[joelmoss]

I handle this implicit rendering with https://github.com/joelmoss/phlexible/#actioncontrollerimplicitrender

It works really well with the responders gem too :)

[pinzonjulian]

@joeldrapper I like the view method as a shortcut!

However I'm intrigued by @joelmoss 's option.

@joelmoss could you give us an example of implicit rendering on a view with arguments that doesn't user responders?

[joelmoss]

ah well without responders, you would have to be explicit, and call render in the action yourself. Without resorting to instance variables (like rails already does), there is no way to pass vars to the view.

[joeldrapper]

This is pretty interesting related to the above https://github.com/rocketshipio/oxidizer

[bradgessler]

Here's my take (after flexing 💪 Phlex at https://fly.io/ruby-dispatch/component-driven-development-on-rails-with-phlex/):

• I ❤️ inline Phlex views in controllers for prototyping applications, or for really small Rails applications. I love how it feels building small apps in Sinatra, but then when I need to add more functionality to them, I usually regret not using Rails. This approach is the best of both worlds.
• When an app gets bigger and/or it makes sense to move views out of the controller, the "obvious" thing is to have them live in a location Rails devs are already familiar with: ./views/:name/:action.rb. An implicit renderer could resolve that view const_get Views::#{:name.camelcase}::#{:action.camelcase}. My only beef with this is I think it sucks how "far away" views are from controllers in Rails. That said, I still think this use case should be supported because people have been doing it this way for over a decade.
• What I think would be better is to have the views "closer to the controller". The closest is inline, but after that maybe they could live in a folder like app/controllers/:name/:action.rb. For example, the show view for BlogsController would be located in app/controllers/blogs/show.rb. This particular recommendation feels half-baked to me, so I'd look forward to other ideas for this. In a more perfect world Rails controllers would be named spaced differently, but we're not there (the potential will be in 7.1). If we want to get more RESTful about it, maybe the format is included like app/controllers/blogs/show.html.rb, app/controllers/blogs/show.json.rb, etc.

[joeldrapper]

I like the idea of including the format in the file name when there are multiple file formats. I don't know if Zeitwerk could support that though and it's not clear what the constant would be. Perhaps another namespace would be better, e.g. app/views/json/articles/show.rb.

[bradgessler]

I’ve thought about what I’d do for inline Phlex html classes with JSON classes and landed on namespacing them in a format, like this:

class Controller
  module HTML
    class Show # …
    class Edit # …
  end

  module JSON
    class Show # …
    class Edit # …
  end
end

There’s some things I don’t love about this approach, but assuming it’s sound, it would imply view directories like ./app/views/:name/:format/:action

I’m pretty sure Zeitwork can be hacked to handle stripping the format from the path when it resolves the constants. It’s def a custom loader, but I’m 98% sure it’s possible without gross hacks.

[hansondr]

Building off the ideas here

• Joel Moss
• Joel Drapper, re: Oxidizer code

I added the following to my Rails project:

# lib/phlex/rails/implicit_render.rb

module Phlex
  module Rails
    module ImplicitRender
      def default_render
        render_phlex_view({ action: action_name }) || super
      end

      def method_for_action(action_name)
        super || ("default_phlex_render" if phlex_view(action_name))
      end

      def default_phlex_render
        render phlex_view(action_name)
      end

      def render_phlex_view(options)
        options[:action] ||= action_name

        return unless (view = phlex_view(options[:action]))

        render view, options
      end

      private

      def phlex_view(action_name = @_action_name)
        assign_ivars phlex_view_path(action_name).camelize.safe_constantize.new
      end

      def phlex_view_path(action_name)
        "#{controller_path}/#{action_name}_view"
      end

      def assign_ivars(phlex_view)
        phlex_view.tap do |view|
          view_assigns.each do |variable, value|
            attr_writer_name = "#{variable}="
            view.send attr_writer_name, value if view.respond_to?(attr_writer_name)
            warn "[#{phlex_view.class.name}] Unprocessed ivar (@#{variable}).  To correct add `attr_writer :#{variable}` or `def #{variable}=(value)` to this Phlex View" if ::Rails.env.development? && !view.respond_to?(attr_writer_name)
          end
        end
      end
    end
  end
end

I then updated my ApplicationController

class ApplicationController < ActionController::Base
  include Phlex::Rails::ImplicitRender
  layout -> { ApplicationLayout }

  allow_browser versions: :modern
end

Example Controller

# app/controllers/dashboards_controller.rb

class DashboardsController < ApplicationController
  def show
    @greeting = "Hiya"
    @unknown = 42
    @another_one = "Khaled"
  end
end

Example Phlex View

# app/views/dashboards/show_view.rb

class Dashboards::ShowView < ApplicationView
  attr_writer :greeting

  def view_template
    h1 { "Dashboards::ShowView" }
    p { "#{@greeting}, User!" }
  end
end

The dev log warns of the ivars defined but unused because the view lacks the ability to accept them:

18:48:59 web.1  | Started GET "/" for 127.0.0.1 at 2024-06-21 18:48:59 +0000
18:48:59 web.1  | Processing by DashboardsController#show as HTML
18:48:59 web.1  | [Dashboards::ShowView] Unprocessed ivar (@unknown).  To correct add `attr_writer :unknown` or `def unknown=(value)` to this Phlex View
18:48:59 web.1  | [Dashboards::ShowView] Unprocessed ivar (@another_one).  To correct add `attr_writer :another_one` or `def another_one=(value)` to this Phlex View
18:48:59 web.1  |   Rendering layout ApplicationLayout
18:48:59 web.1  |   Rendering Dashboards::ShowView within application_layout
18:48:59 web.1  |   Rendered Dashboards::ShowView within application_layout (Duration: 0.2ms | GC: 0.0ms)
18:48:59 web.1  |   Rendered layout ApplicationLayout (Duration: 1.8ms | GC: 0.0ms)
18:48:59 web.1  | Completed 200 OK in 15ms (Views: 3.3ms | ActiveRecord: 0.0ms (0 queries, 0 cached) | GC: 0.0ms)