Rails 7.1 doesn't render Enumerator in view correctly about rails HOT 7 CLOSED

whether the forced stringifiement was intentional and is now a core ActionView expectation?

It kinda is yes. At least when there is multiple templates involved.

But I'll try to find some time to have a look if we could keep supporting the case outlined in the repro script (a single template that returns something responding to :each).

from rails.

We are facing a similar issue with https://github.com/cheddar-me/rails-twirp at the moment - our rendering assigns the return value of the view to an instance variable via the ActionController rendering mechanics, but that return value is actually a Proto::Message - not a rendered string, and that is deliberate. With 7.1 everything gets stringified, due to this bit in ActionView actually:

There is a forced string conversion that has been added with &.to_s - since there is no specification on what render must return or set exactly (what type) I wonder what the reasoning was for this change. For us this works correctly on 7.0x but broke on 7.1 and the only thing I could imagine we could do is subclass ActionView::Template

@eileencodes was there any decision made we should be aware of that "anything that renders must return strings or else" by any chance?

from rails.

As a result of git bisect, the first commit that introduced this issue seems to be 4e8e828.

from rails.

Oh - thank you for the bisect @kuwabarahiroshi Interesting! @byroot could you help us out figuring out whether the forced stringifiement was intentional and is now a core ActionView expectation? Because it would mean that anything renderable must render strings 🤔

from rails.

That would be unfortunate because it means that it becomes impossible for a template to set a pre-filled object somewhere for later manipulation. While it will work for an enumerator, I wonder whether there should be a hook someplace where non-serialized rendered outputs could be accommodated. For example, in our library we generate a proto message and then either embed it inside another or manipulate it in some way (using after of the controller and similar). One could say this is a corner case, but at the same time - ActionView used to allow this, and the behaviour changed. If we want to do some manipulation on protos for instance, we would then need to unmarshal them and then change them. Besides, protos are not streaming - so would be even less efficient 😢 Could there be a way to bypass the buffer path?

from rails.

As I said I'll have a look. In the meantime what would be useful would be to provide a repro script so I can see how hard it would be to restore that capability without losing the perf gains.

Unless of course the already provided Enumerator example is representative enough of your use case.

from rails.

In my case, the real use case is to render CSV in view and returning as a streaming response.

# controllers/records_controller.rb
class RecordsController < ApplicationController
  def index
    @records = Record.all
  end
end

# views/records/index.html.erb
# providing paginated view for html format
<% @records.page(params[:page]).each do |r| %>
  <p><%= r.id %></p>
<% end %>

# views/records/index.csv.ruby
# providing all records for CSV format in streaming response
headers['Content-Disposition'] = "attachment; filename=records.csv"
Enumerator.new do |buff|
  @records.find_each do |r|
    buff << CSV.generate_line([r.id, r.name])
  end
end

In this case, it'll be covered by @byroot 's proposal (a single template that returns something responding to :each)

from rails.