PoC: AbstractController::Base#renderer_for

[casperisfine]

Context

There has been some demands from view systems not based on paths, to offer some extension API that are better suited for them: https://discuss.rubyonrails.org/t/replace-to-partial-path-calls-with-a-more-abstract-to-renderable/81457

I'm in favor of the general idea, but not at all with the proposed solutions so far.

Existing API

Currently you can customize the behavior of render some_object in two ways:

• The object can respond to to_partial_path and return a view path.
• The object can respond to render_in and return a string representation.

What I don't like with both of these APIs is that they ask the object how to render itself. Applications often have several different ways to represent the same object based on the context, e.g. frontend vs admin panel, or HTML vs JSON.

Proposal

It would be way more powerful if the view or controller was in charge of selecting the proper renderer for a given object.

e.g. (pseudo code)

module Admin
  class BaseController < ApplicationController
    def renderer_for(object)
      { partial: "admin/#{object.class.underscore}" }
    end
  end

On paper, you'd probably want to define this on thew view, but in practive Rails users very rarely interact with the view, hence why I do this on the controller. But I'm maybe missing something.

Another benefit of such API would be to allow view component systems to better integrate with Rails by implementing their own conventions, e.g. (pseudo code)

module MyViewComponentExtension
  def renderer_for(object)
    component_name = "#{object.class.name}Component"
    "#{self.class.module_parent_name}#{component_name}".safe_constantize ||
      component_name.constantize
  end
end

It's somewhat similar to what Active Model Serializer used to do for its default serializer system:
https://github.com/rails-api/active_model_serializers/blob/0-9-stable/lib/action_controller/serialization.rb

It used to work quite well.

Note

his is purely a proof of concept to demonstrate the general idea, what capabilities it brings to the table.

I'm absolutely not happy with that implementation and I'm not suggesting to merge it. If we chose to go with the idea, we
should carefully study what the API would look like.

[paracycle]

I like this proposal but the only thing that bothers me is dropping the to_partial_path dependency. While the name of the method is bad, I think the "partial path" plays the role of a resource locator on the server side, and if we can decouple them from actual view paths on disk for a second, they would provide them most flexible way to decide how to render an object. This is similar to how URL paths can correspond to file locations on disk on the server, but don't have to.

In that sense, I would prefer if the API was similar to:

class ApplicationController
  def renderer_for(partial_path)
    if should_be_rendered_by_action_view?(partial_path)
      { partial: partial_path }
    else
      find_renderer_for(partial_path)
    end
  end
end

[casperisfine]

@paracycle part of the reason is that not all rendering system are tied to file system paths, e.g. ViewComponent, Active Model Serializers, etc. I think we should try to support these better.

[seanpdoyle]

@byroot I've opened #50623 to expand the capabilities of the render_in method to incorporate options like :locals passed at the render site.

On that heels of that change, I've also started to explore expanding ActiveModel::Conversion to define a baseline render_in implementation that preserves the existing behavior in a backwards compatible way: seanpdoyle#2

What I don't like with both of these APIs is that they ask the object how to render itself. Applications often have several different ways to represent the same object based on the context, e.g. frontend vs admin panel, or HTML vs JSON.

I relate to this concern. The motivation behind making options available to render_in aims to give the renderable more context. Through the view_context argument, the object can access the available variants, and the :formats (HTML, JSON, etc.) would be available through the :formats option or the lookup_context.

From an Action View perspective, that information could enable some flexibility. From a third-party integration perspective (like ViewComponent or Active Model Serializers), then information could be used to make similar encoding decisions.

These proposed changes are still at a different application layer than this PR (#46202), but they share similar goals.