Turbo-Streaming ViewComponents

[cpjmcquillan]

Feature request

Provide an interface for rendering view components outside the context of a request-response cycle (e.g without depending on a controller or view context).

Motivation

Rails 7 ships with Hotwire by default. Turbo Streams are a component of Hotwire that (among other things) allow applications to broadcast HTML "over the wire" based on model changes.

Like Rails, Turbo Streams lean heavily on partials - although you can now broadcast HTML from the model. Since ViewComponents replace partials in lots of scenarios, I think it would be beneficial for the library to integrate seamlessly with Turbo Streams in the same way partials do.

Currently there are few ways to integrate ViewComponents with Turbo Streams, but I think it would be nice to offer an "approved" approach.

• We can use #render_in(view_context) to broadcast HTML from a controller.
• If a component implements a #call method we can invoke it to return HTML and broadcast from a model (or any other class).
• We can render the component inside a view partial and broadcast from a model (or any other class).

Context

Turbo broadcasting discussion
Hotwire by default in Rails 7

[cpjmcquillan]

If this is something we feel is worth implementing I would love to hear people's ideas for how it could work, and I love to pair on the feature.

[boardfish]

Right now, I actually need this feature for something I'm working on @raisedevs. I'm going to be working on a cleaner solution at some point in the future, but right now I can recommend using partials as a compatibility layer here. Either render what you want to directly in the partial, or render a component inside the partial. The latter should make it much easier to switch to the solution once it arises.

[boardfish]

I've taken some time to battle with this one, and here are my findings:

Turbo::StreamsChannel.broadcast_append_to(record_or_channel_name, target: dom_target_id, html: ExampleComponent.new.render_in(view_context))

We can use any of the methods from off Turbo::StreamsChannel, which is what turbo-rails uses internally, to broadcast to the same model channels Turbo would be using. This is what that looks like in the context of a controller, and it wouldn't take much to adapt that to a component.

I think some of their Broadcastable concern is applicable to ViewComponent, but some of it is pointed at self (usually a record), which makes it less applicable. Maybe the two could be broken apart within Turbo and we could use the helpers that we need.

[boardfish]

I think what's particularly notable about the above is that a view context is necessary. That makes it less than optimal for using in Active Record callbacks, which (while not my personal preference) is the way they introduce you to it in the Turbo docs, so some Turbo folks would most likely expect this usage to integrate with ViewComponent.

[cpjmcquillan]

I've been leaning on objects like this for now.

module Broadcast
  class Message
    def self.append(message:, view_context:)
      new(message, view_context).append
    end

    def initialize(message, view_context)
      @message = message
      @view_context = view_context
    end

    def append
      Turbo::StreamsChannel.broadcast_append_later_to(
        :messages,
        target: "messages",
        html: rendered_component
      )
    end

    private

    attr_reader :message, :view_context

    def rendered_component
      MessageComponent.new(message: message).render_in(view_context)
    end
  end
end

I think what I'd like to be able to do is something like this - which would mean we don't rely on a view_context to broadcast components.

class Message < ApplicationRecord
  belongs_to :user

  after_create_commit :update_message_count

  private
  
  def update_message_count
    broadcast_update_to(
      user, 
      :messages, 
      target: "message-count", 
      html: CountComponent.new(count: user.messages.count).render_to_html
    )
  end
end

[boardfish]

I suppose there's still the wider question of components that inherently rely on a view context - say, for example, you're using current_user, form_with, or other notable helpers - and how they'd interact with this.

At one point there was talk of making a new instance of ActionView::Base the default value for the view_context arg to render_in, but that was scrapped. I've had luck using ActionController::Base instead, though. I'll revive discussion on #201 so we can come to a decision about it, because it's a prerequisite for this.

[boardfish]

Been dwelling on this a bit and I think this requires very little in the way of code at all. I think what it comes down to is folks:

• using render_in to render the component to a string and passing that as the html arg to either Turbo's Broadcastable methods or direct usage of Turbo::StreamsChannel
• uniquely identifying rendered components and redefining broadcast_target_default to reflect that if the solution calls for it

One thing we probably don't want to do is create methods on component instances to broadcast them directly, e.g. ExampleComponent.new.broadcast_to(stream, insert_by: :append). Personally I don't think it's a component's responsibility to render itself and then broadcast that output elsewhere.

We'll definitely want to make it easier to render components to strings in order to enable this, and document the approach too.

[boardfish]

The only thing I can think of that we might want to do is take the top-level broadcast helpers a bit further by allowing folks to pass the html option, so that they can render a component instead of going with the default partial. But whether that's even our concern is another question - perhaps it needs to be done over on turbo-rails.

[Spone]

@boardfish What about adding a section about Turbo on the Compatibility page?

[boardfish]

That sounds right, but I think if the aim is for it to be saying to folks "ViewComponent works with X!", we might need to break it down a bit, since a lot of what's there feels like it's saying "ViewComponent works with X, but you have to pull these strings to do it".

Rendering to a string is currently in the FAQs, so I'll probably link to that from there.

[DavidColby]

@boardfish Apologies if I'm missing something simple here.

I spent some time today working on broadcasting view components from models, based on your work here and in #201. I started with this:

# app/models/post.rb
broadcast_append_to(
  'posts',
  html: PostComponent.new(post: self).render_in(ActionController::Base.new.view_context)
)

This worked up until the point that I needed to access url helpers in the component, like this:

<%= link_to "Show this post", @post %>

At that point, the model broadcast failed with In order to use #url_for, you must include routing helpers explicitly. For instance, include Rails.application.routes.url_helpers.

Adding include Rails.application.routes.url_helpers to the component didn't resolve the issue and I kind of ran into a wall with getting it working with render_in when my component needed access to url helpers.

Eventually I switched to using ApplicationController.render instead, which seemed to Just Work™, but I'm not nearly comfortable enough with view_component to know if I'm missing something here:

broadcast_append_to(
  'posts',
  html: ApplicationController.render(
    PostComponent.new(post: self)
  )
)

Is there a reason not to use ApplicationController.render to render the component in a stream broadcast when you don't have access to the normal view context?

[boardfish]

Is there a reason not to use ApplicationController.render to render the component in a stream broadcast when you don't have access to the normal view context?

I don't think there is. The docs currently specify that if you want to render to a string from inside a controller action, you would do so through render_in, which is why I suggested it in the first instance. But if this works, it's better.

The difference in behavior between these two methods interests me - again, it's got me thinking about the trend of calling helpers without chaining off helpers and the inconsistent behavior that seems to have.

I wonder if using ActionController::Base.render is also our solution to #201, but I also don't know where that leaves render_in. It's part of a component's public API, but if its behavior seemingly isn't equivalent to ActionController::Base.render, that's odd.

[yshmarov]

currently all of these work for me without any additional magic

turbo_stream.update('inboxes-pagination', render_to_string(PaginationComponent.new(results: @results))),
turbo_stream.update("inboxes-pagination", view_context.render(PaginationComponent.new(results: @results))),
turbo_stream.update("inboxes-pagination", PaginationComponent.new(results: @results).render_in(view_context))

more details: https://blog.corsego.com/turbo-stream-view-components

update: sorry for the confusion: this works for me in a controller. did not try in model broadcast