Skip to content

Render objects that respond_to render_in in controllers #37919

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
eileencodes merged 2 commits into from
Dec 10, 2019
Merged

Render objects that respond_to render_in in controllers #37919

eileencodes merged 2 commits into from
Dec 10, 2019

Conversation

@joelhawksley
Copy link
Contributor

@joelhawksley joelhawksley commented Dec 9, 2019

In #36388, we supported passing objects that respond_to render_in
to render, but only in views.

This change does the same for controllers, as Rails
generally gives the expectation that render behaves
the same in both contexts.

Co-authored-by: Aaron Patterson [email protected]

@joelhawksley @tenderlove
Render objects that respond_to render_in in controllers
20a83f5 
In #36388,
we supported passing objects that `respond_to` `render_in`
to `render`, but _only_ in views.

This change does the same for controllers, as Rails
generally gives the expectation that `render` behaves
the same in both contexts.

Co-authored-by: Aaron Patterson <[email protected]>
@joelhawksley joelhawksley changed the title Controller render in Render objects that respond_to render_in in controllers Dec 9, 2019
@eileencodes eileencodes merged commit e36097a into rails:master Dec 10, 2019
@joelhawksley joelhawksley deleted the controller-render-in branch December 10, 2019 14:58
@joelhawksley joelhawksley mentioned this pull request Dec 19, 2019
Closed
@joelhawksley joelhawksley mentioned this pull request Jan 31, 2020
Closed
@joelhawksley joelhawksley mentioned this pull request Feb 20, 2020
Merged
joelhawksley added a commit to ViewComponent/view_component that referenced this pull request Feb 28, 2020
@joelhawksley
add rudimentary support for rendering components from controllers
2b950d5 
This change introduces the ability to render components from
controllers, mimicking the behavior introduced in
rails/rails#37919.

[Fixes: #21]
joelhawksley added a commit to ViewComponent/view_component that referenced this pull request Feb 28, 2020
@joelhawksley
add rudimentary support for rendering components from controllers
a5810c8 
This change introduces the ability to render components from
controllers, mimicking the behavior introduced in
rails/rails#37919.

[Fixes: #38]
joelhawksley added a commit to ViewComponent/view_component that referenced this pull request Feb 28, 2020
@joelhawksley
add rudimentary support for rendering components from controllers
b76a6a3 
This change introduces the ability to render components from
controllers, mimicking the behavior introduced in
rails/rails#37919.

[Fixes: #38]
joelhawksley added a commit to ViewComponent/view_component that referenced this pull request Feb 28, 2020
@joelhawksley
add rudimentary support for rendering components from controllers
2fd5aaf 
This change introduces the ability to render components from
controllers, mimicking the behavior introduced in
rails/rails#37919.

[Fixes: #38]
joelhawksley added a commit to ViewComponent/view_component that referenced this pull request Feb 28, 2020
@joelhawksley
add rudimentary support for rendering components from controllers
405be99 
This change introduces the ability to render components from
controllers, mimicking the behavior introduced in
rails/rails#37919.

[Fixes: #38]
This was referenced Feb 28, 2020
Merged
Merged
@joelhawksley joelhawksley mentioned this pull request Jul 17, 2020
Merged
seanpdoyle added a commit to seanpdoyle/rails that referenced this pull request Jan 6, 2024
@seanpdoyle
Pass render options and block to calls to #render_in
1b7efc9 
Closes [rails#45432][]

Support for objects that respond to `#render_in` was introduced in
[rails#36388][] and [rails#37919][]. Those implementations assume that the
instance will all the context it needs to render itself. That assumption
doesn't account for call-site arguments like `locals: { ... }` or a
block.

This commit expands support for rendering with a `:renderable` option to
incorporate locals and blocks. For example:

```ruby
class Greeting
  def render_in(view_context, **options, &block)
    if block
      view_context.render html: block.call
    else
      view_context.render inline: <<~ERB.strip, **options
        <%= Hello, <%= name %>
      ERB
    end
  end
end

render(Greeting.new)                    # => "Hello, World"
render(Greeting.new, name: "Local")     # => "Hello, Local"
render(Greeting.new) { "Hello, Block" } # => "Hello, Block"
```

[rails#45432]: rails#45432
[rails#36388]: rails#36388
[rails#37919]: rails#37919
seanpdoyle added a commit to seanpdoyle/rails that referenced this pull request Jan 6, 2024
@seanpdoyle
Pass render options and block to calls to #render_in
40fe274 
Closes [rails#45432][]

Support for objects that respond to `#render_in` was introduced in
[rails#36388][] and [rails#37919][]. Those implementations assume that the
instance will all the context it needs to render itself. That assumption
doesn't account for call-site arguments like `locals: { ... }` or a
block.

This commit expands support for rendering with a `:renderable` option to
incorporate locals and blocks. For example:

```ruby
class Greeting
  def render_in(view_context, **options, &block)
    if block
      view_context.render html: block.call
    else
      view_context.render inline: <<~ERB.strip, **options
        <%= Hello, <%= name %>
      ERB
    end
  end
end

render(Greeting.new)                    # => "Hello, World"
render(Greeting.new, name: "Local")     # => "Hello, Local"
render(Greeting.new) { "Hello, Block" } # => "Hello, Block"
```

[rails#45432]: rails#45432
[rails#36388]: rails#36388
[rails#37919]: rails#37919
seanpdoyle added a commit to seanpdoyle/rails that referenced this pull request Jan 6, 2024
@seanpdoyle
Pass render options and block to calls to #render_in
4ff0f39 
Closes [rails#45432][]

Support for objects that respond to `#render_in` was introduced in
[rails#36388][] and [rails#37919][]. Those implementations assume that the
instance will all the context it needs to render itself. That assumption
doesn't account for call-site arguments like `locals: { ... }` or a
block.

This commit expands support for rendering with a `:renderable` option to
incorporate locals and blocks. For example:

```ruby
class Greeting
  def render_in(view_context, **options, &block)
    if block
      view_context.render html: block.call
    else
      view_context.render inline: <<~ERB.strip, **options
        <%= Hello, <%= name %>
      ERB
    end
  end
end

render(Greeting.new)                    # => "Hello, World"
render(Greeting.new, name: "Local")     # => "Hello, Local"
render(Greeting.new) { "Hello, Block" } # => "Hello, Block"
```

[rails#45432]: rails#45432
[rails#36388]: rails#36388
[rails#37919]: rails#37919
seanpdoyle added a commit to seanpdoyle/rails that referenced this pull request Jan 6, 2024
@seanpdoyle
Pass render options and block to calls to #render_in
f02d67f 
Closes [rails#45432][]

Support for objects that respond to `#render_in` was introduced in
[rails#36388][] and [rails#37919][]. Those implementations assume that the
instance will all the context it needs to render itself. That assumption
doesn't account for call-site arguments like `locals: { ... }` or a
block.

This commit expands support for rendering with a `:renderable` option to
incorporate locals and blocks. For example:

```ruby
class Greeting
  def render_in(view_context, **options, &block)
    if block
      view_context.render html: block.call
    else
      view_context.render inline: <<~ERB.strip, **options
        <%= Hello, <%= name %>
      ERB
    end
  end
end

render(Greeting.new)                    # => "Hello, World"
render(Greeting.new, name: "Local")     # => "Hello, Local"
render(Greeting.new) { "Hello, Block" } # => "Hello, Block"
```

[rails#45432]: rails#45432
[rails#36388]: rails#36388
[rails#37919]: rails#37919
seanpdoyle added a commit to seanpdoyle/rails that referenced this pull request Jan 6, 2024
@seanpdoyle
Pass render options and block to calls to #render_in
ed983ca 
Closes [rails#45432][]

Support for objects that respond to `#render_in` was introduced in
[rails#36388][] and [rails#37919][]. Those implementations assume that the
instance will all the context it needs to render itself. That assumption
doesn't account for call-site arguments like `locals: { ... }` or a
block.

This commit expands support for rendering with a `:renderable` option to
incorporate locals and blocks. For example:

```ruby
class Greeting
  def render_in(view_context, **options, &block)
    if block
      view_context.render html: block.call
    else
      view_context.render inline: <<~ERB.strip, **options
        <%= Hello, <%= name %>
      ERB
    end
  end
end

render(Greeting.new)                    # => "Hello, World"
render(Greeting.new, name: "Local")     # => "Hello, Local"
render(Greeting.new) { "Hello, Block" } # => "Hello, Block"
```

[rails#45432]: rails#45432
[rails#36388]: rails#36388
[rails#37919]: rails#37919
@seanpdoyle seanpdoyle mentioned this pull request Jan 6, 2024
Open
4 tasks
seanpdoyle added a commit to seanpdoyle/rails that referenced this pull request Jan 8, 2024
@seanpdoyle
Pass render options and block to calls to #render_in
e55d1bc 
Closes [rails#45432][]

Support for objects that respond to `#render_in` was introduced in
[rails#36388][] and [rails#37919][]. Those implementations assume that the
instance will all the context it needs to render itself. That assumption
doesn't account for call-site arguments like `locals: { ... }` or a
block.

This commit expands support for rendering with a `:renderable` option to
incorporate locals and blocks. For example:

```ruby
class Greeting
  def render_in(view_context, **options, &block)
    if block
      view_context.render plain: block.call
    else
      case Array(options[:formats]).first
      when :json
        view_context.render json: { greeting: "Hello, World!" }
      else
        view_context.render **options, inline: "<%= Hello, <%= name %>!"
      end
    end
  end
end

render(Greeting.new)                              # => "Hello, World!"
render(Greeting.new, name: "Local")               # => "Hello, Local!"
render(Greeting.new) { "Hello, Block!" }          # => "Hello, Block!"

render(renderable: Greeting.new, formats: :json)  # => "{\"greeting\":\"Hello, World!\"}"
```

[rails#45432]: rails#45432
[rails#36388]: rails#36388
[rails#37919]: rails#37919
seanpdoyle added a commit to seanpdoyle/rails that referenced this pull request Jan 8, 2024
@seanpdoyle
Pass render options and block to calls to #render_in
0ba4642 
Closes [rails#45432][]

Support for objects that respond to `#render_in` was introduced in
[rails#36388][] and [rails#37919][]. Those implementations assume that the
instance will all the context it needs to render itself. That assumption
doesn't account for call-site arguments like `locals: { ... }` or a
block.

This commit expands support for rendering with a `:renderable` option to
incorporate locals and blocks. For example:

```ruby
class Greeting
  def render_in(view_context, **options, &block)
    if block
      view_context.render plain: block.call
    else
      case Array(options[:formats]).first
      when :json
        view_context.render json: { greeting: "Hello, World!" }
      else
        view_context.render **options, inline: "<%= Hello, <%= name %>!"
      end
    end
  end
end

render(Greeting.new)                              # => "Hello, World!"
render(Greeting.new, name: "Local")               # => "Hello, Local!"
render(Greeting.new) { "Hello, Block!" }          # => "Hello, Block!"

render(renderable: Greeting.new, formats: :json)  # => "{\"greeting\":\"Hello, World!\"}"
```

[rails#45432]: rails#45432
[rails#36388]: rails#36388
[rails#37919]: rails#37919
seanpdoyle added a commit to seanpdoyle/rails that referenced this pull request Jan 8, 2024
@seanpdoyle
Pass render options and block to calls to #render_in
e6a401d 
Closes [rails#45432][]

Support for objects that respond to `#render_in` was introduced in
[rails#36388][] and [rails#37919][]. Those implementations assume that the
instance will all the context it needs to render itself. That assumption
doesn't account for call-site arguments like `locals: { ... }` or a
block.

This commit expands support for rendering with a `:renderable` option to
incorporate locals and blocks. For example:

```ruby
class Greeting
  def render_in(view_context, **options, &block)
    if block
      view_context.render plain: block.call
    else
      case Array(options[:formats]).first
      when :json
        view_context.render json: { greeting: "Hello, World!" }
      else
        view_context.render **options, inline: "<%= Hello, <%= name %>!"
      end
    end
  end
end

render(Greeting.new)                              # => "Hello, World!"
render(Greeting.new, name: "Local")               # => "Hello, Local!"
render(Greeting.new) { "Hello, Block!" }          # => "Hello, Block!"

render(renderable: Greeting.new, formats: :json)  # => "{\"greeting\":\"Hello, World!\"}"
```

[rails#45432]: rails#45432
[rails#36388]: rails#36388
[rails#37919]: rails#37919
seanpdoyle added a commit to seanpdoyle/rails that referenced this pull request Jan 9, 2024
@seanpdoyle
Pass render options and block to calls to #render_in
6276610 
Closes [rails#45432][]

Support for objects that respond to `#render_in` was introduced in
[rails#36388][] and [rails#37919][]. Those implementations assume that the
instance will all the context it needs to render itself. That assumption
doesn't account for call-site arguments like `locals: { ... }` or a
block.

This commit expands support for rendering with a `:renderable` option to
incorporate locals and blocks. For example:

```ruby
class Greeting
  def render_in(view_context, **options, &block)
    if block
      view_context.render plain: block.call
    else
      case Array(options[:formats]).first
      when :json
        view_context.render json: { greeting: "Hello, World!" }
      else
        view_context.render **options, inline: "<%= Hello, <%= name %>!"
      end
    end
  end
end

render(Greeting.new)                              # => "Hello, World!"
render(Greeting.new, name: "Local")               # => "Hello, Local!"
render(Greeting.new) { "Hello, Block!" }          # => "Hello, Block!"

render(renderable: Greeting.new, formats: :json)  # => "{\"greeting\":\"Hello, World!\"}"
```

Since existing tools depend on the `#render_in(view_context)` signature
without options, this commit deprecates that signature in favor of one
that accepts options and a block.

[rails#45432]: rails#45432
[rails#36388]: rails#36388
[rails#37919]: rails#37919
seanpdoyle added a commit to seanpdoyle/rails that referenced this pull request Jan 9, 2024
@seanpdoyle
Pass render options and block to calls to #render_in
8a1754a 
Closes [rails#45432][]

Support for objects that respond to `#render_in` was introduced in
[rails#36388][] and [rails#37919][]. Those implementations assume that the
instance will all the context it needs to render itself. That assumption
doesn't account for call-site arguments like `locals: { ... }` or a
block.

This commit expands support for rendering with a `:renderable` option to
incorporate locals and blocks. For example:

```ruby
class Greeting
  def render_in(view_context, **options, &block)
    if block
      view_context.render plain: block.call
    else
      case Array(options[:formats]).first
      when :json
        view_context.render json: { greeting: "Hello, World!" }
      else
        view_context.render **options, inline: "<%= Hello, <%= name %>!"
      end
    end
  end
end

render(Greeting.new)                              # => "Hello, World!"
render(Greeting.new, name: "Local")               # => "Hello, Local!"
render(Greeting.new) { "Hello, Block!" }          # => "Hello, Block!"

render(renderable: Greeting.new, formats: :json)  # => "{\"greeting\":\"Hello, World!\"}"
```

Since existing tools depend on the `#render_in(view_context)` signature
without options, this commit deprecates that signature in favor of one
that accepts options and a block.

[rails#45432]: rails#45432
[rails#36388]: rails#36388
[rails#37919]: rails#37919
seanpdoyle added a commit to seanpdoyle/rails that referenced this pull request Jan 9, 2024
@seanpdoyle
Pass render options and block to calls to #render_in
cb1b21b 
Closes [rails#45432][]

Support for objects that respond to `#render_in` was introduced in
[rails#36388][] and [rails#37919][]. Those implementations assume that the
instance will all the context it needs to render itself. That assumption
doesn't account for call-site arguments like `locals: { ... }` or a
block.

This commit expands support for rendering with a `:renderable` option to
incorporate locals and blocks. For example:

```ruby
class Greeting
  def render_in(view_context, **options, &block)
    if block
      view_context.render plain: block.call
    else
      case Array(options[:formats]).first
      when :json
        view_context.render json: { greeting: "Hello, World!" }
      else
        view_context.render **options, inline: "<%= Hello, <%= name %>!"
      end
    end
  end
end

render(Greeting.new)                              # => "Hello, World!"
render(Greeting.new, name: "Local")               # => "Hello, Local!"
render(Greeting.new) { "Hello, Block!" }          # => "Hello, Block!"

render(renderable: Greeting.new, formats: :json)  # => "{\"greeting\":\"Hello, World!\"}"
```

Since existing tools depend on the `#render_in(view_context)` signature
without options, this commit deprecates that signature in favor of one
that accepts options and a block.

[rails#45432]: rails#45432
[rails#36388]: rails#36388
[rails#37919]: rails#37919
seanpdoyle added a commit to seanpdoyle/rails that referenced this pull request Jan 12, 2024
@seanpdoyle
Pass render options and block to calls to #render_in
981465e 
Closes [rails#45432][]

Support for objects that respond to `#render_in` was introduced in
[rails#36388][] and [rails#37919][]. Those implementations assume that the
instance will all the context it needs to render itself. That assumption
doesn't account for call-site arguments like `locals: { ... }` or a
block.

This commit expands support for rendering with a `:renderable` option to
incorporate locals and blocks. For example:

```ruby
class Greeting
  def render_in(view_context, **options, &block)
    if block
      view_context.render plain: block.call
    else
      case Array(options[:formats]).first
      when :json
        view_context.render json: { greeting: "Hello, World!" }
      else
        view_context.render **options, inline: "<%= Hello, <%= name %>!"
      end
    end
  end

  def format
    :html
  end
end

render(Greeting.new)                              # => "Hello, World!"
render(Greeting.new, name: "Local")               # => "Hello, Local!"
render(Greeting.new) { "Hello, Block!" }          # => "Hello, Block!"

render(renderable: Greeting.new, formats: :json)  # => "{\"greeting\":\"Hello, World!\"}"
```

Since existing tools depend on the `#render_in(view_context)` signature
without options, this commit deprecates that signature in favor of one
that accepts options and a block.

[rails#45432]: rails#45432
[rails#36388]: rails#36388
[rails#37919]: rails#37919
seanpdoyle added a commit to seanpdoyle/rails that referenced this pull request Jan 12, 2024
@seanpdoyle
Pass render options and block to calls to #render_in
7dac0ab 
Closes [rails#45432][]

Support for objects that respond to `#render_in` was introduced in
[rails#36388][] and [rails#37919][]. Those implementations assume that the
instance will all the context it needs to render itself. That assumption
doesn't account for call-site arguments like `locals: { ... }` or a
block.

This commit expands support for rendering with a `:renderable` option to
incorporate locals and blocks. For example:

```ruby
class Greeting
  def render_in(view_context, **options, &block)
    if block
      view_context.render plain: block.call
    else
      case Array(options[:formats]).first
      when :json
        view_context.render json: { greeting: "Hello, World!" }
      else
        view_context.render **options, inline: "<%= Hello, <%= name %>!"
      end
    end
  end

  def format
    :html
  end
end

render(Greeting.new)                              # => "Hello, World!"
render(Greeting.new, name: "Local")               # => "Hello, Local!"
render(Greeting.new) { "Hello, Block!" }          # => "Hello, Block!"

render(renderable: Greeting.new, formats: :json)  # => "{\"greeting\":\"Hello, World!\"}"
```

Since existing tools depend on the `#render_in(view_context)` signature
without options, this commit deprecates that signature in favor of one
that accepts options and a block.

[rails#45432]: rails#45432
[rails#36388]: rails#36388
[rails#37919]: rails#37919
seanpdoyle added a commit to seanpdoyle/rails that referenced this pull request Jan 12, 2024
@seanpdoyle
Pass render options and block to calls to #render_in
8f14f10 
Closes [rails#45432][]

Support for objects that respond to `#render_in` was introduced in
[rails#36388][] and [rails#37919][]. Those implementations assume that the
instance will all the context it needs to render itself. That assumption
doesn't account for call-site arguments like `locals: { ... }` or a
block.

This commit expands support for rendering with a `:renderable` option to
incorporate locals and blocks. For example:

```ruby
class Greeting
  def render_in(view_context, **options, &block)
    if block
      view_context.render plain: block.call
    else
      case Array(options[:formats]).first
      when :json
        view_context.render json: { greeting: "Hello, World!" }
      else
        view_context.render **options, inline: "<%= Hello, <%= name %>!"
      end
    end
  end

  def format
    :html
  end
end

render(Greeting.new)                              # => "Hello, World!"
render(Greeting.new, name: "Local")               # => "Hello, Local!"
render(Greeting.new) { "Hello, Block!" }          # => "Hello, Block!"

render(renderable: Greeting.new, formats: :json)  # => "{\"greeting\":\"Hello, World!\"}"
```

Since existing tools depend on the `#render_in(view_context)` signature
without options, this commit deprecates that signature in favor of one
that accepts options and a block.

[rails#45432]: rails#45432
[rails#36388]: rails#36388
[rails#37919]: rails#37919
seanpdoyle added a commit to seanpdoyle/rails that referenced this pull request Jan 12, 2024
@seanpdoyle
Pass render options and block to calls to #render_in
39af464 
Closes [rails#45432][]

Support for objects that respond to `#render_in` was introduced in
[rails#36388][] and [rails#37919][]. Those implementations assume that the
instance will all the context it needs to render itself. That assumption
doesn't account for call-site arguments like `locals: { ... }` or a
block.

This commit expands support for rendering with a `:renderable` option to
incorporate locals and blocks. For example:

```ruby
class Greeting
  def render_in(view_context, **options, &block)
    if block
      view_context.render plain: block.call
    else
      case Array(options[:formats]).first
      when :json
        view_context.render json: { greeting: "Hello, World!" }
      else
        view_context.render **options, inline: "<%= Hello, <%= name %>!"
      end
    end
  end

  def format
    :html
  end
end

render(Greeting.new)                              # => "Hello, World!"
render(Greeting.new, name: "Local")               # => "Hello, Local!"
render(Greeting.new) { "Hello, Block!" }          # => "Hello, Block!"

render(renderable: Greeting.new, formats: :json)  # => "{\"greeting\":\"Hello, World!\"}"
```

Since existing tools depend on the `#render_in(view_context)` signature
without options, this commit deprecates that signature in favor of one
that accepts options and a block.

[rails#45432]: rails#45432
[rails#36388]: rails#36388
[rails#37919]: rails#37919
seanpdoyle added a commit to seanpdoyle/rails that referenced this pull request Jan 30, 2024
@seanpdoyle
Pass render options and block to calls to #render_in
1d390d1 
Closes [rails#45432][]

Support for objects that respond to `#render_in` was introduced in
[rails#36388][] and [rails#37919][]. Those implementations assume that the
instance will all the context it needs to render itself. That assumption
doesn't account for call-site arguments like `locals: { ... }` or a
block.

This commit expands support for rendering with a `:renderable` option to
incorporate locals and blocks. For example:

```ruby
class Greeting
  def render_in(view_context, **options, &block)
    if block
      view_context.render plain: block.call
    else
      case Array(options[:formats]).first
      when :json
        view_context.render json: { greeting: "Hello, World!" }
      else
        view_context.render **options, inline: "<%= Hello, <%= name %>!"
      end
    end
  end

  def format
    :html
  end
end

render(Greeting.new)                              # => "Hello, World!"
render(Greeting.new, name: "Local")               # => "Hello, Local!"
render(Greeting.new) { "Hello, Block!" }          # => "Hello, Block!"

render(renderable: Greeting.new, formats: :json)  # => "{\"greeting\":\"Hello, World!\"}"
```

Since existing tools depend on the `#render_in(view_context)` signature
without options, this commit deprecates that signature in favor of one
that accepts options and a block.

[rails#45432]: rails#45432
[rails#36388]: rails#36388
[rails#37919]: rails#37919
seanpdoyle added a commit to seanpdoyle/rails that referenced this pull request Feb 22, 2024
@seanpdoyle
Pass render options and block to calls to #render_in
4161fe4 
Closes [rails#45432][]

Support for objects that respond to `#render_in` was introduced in
[rails#36388][] and [rails#37919][]. Those implementations assume that the
instance will all the context it needs to render itself. That assumption
doesn't account for call-site arguments like `locals: { ... }` or a
block.

This commit expands support for rendering with a `:renderable` option to
incorporate locals and blocks. For example:

```ruby
class Greeting
  def render_in(view_context, **options, &block)
    if block
      view_context.render plain: block.call
    else
      case Array(options[:formats]).first
      when :json
        view_context.render json: { greeting: "Hello, World!" }
      else
        view_context.render **options, inline: "<%= Hello, <%= name %>!"
      end
    end
  end

  def format
    :html
  end
end

render(Greeting.new)                              # => "Hello, World!"
render(Greeting.new, name: "Local")               # => "Hello, Local!"
render(Greeting.new) { "Hello, Block!" }          # => "Hello, Block!"

render(renderable: Greeting.new, formats: :json)  # => "{\"greeting\":\"Hello, World!\"}"
```

Since existing tools depend on the `#render_in(view_context)` signature
without options, this commit deprecates that signature in favor of one
that accepts options and a block.

[rails#45432]: rails#45432
[rails#36388]: rails#36388
[rails#37919]: rails#37919
seanpdoyle added a commit to seanpdoyle/rails that referenced this pull request Feb 22, 2024
@seanpdoyle
Pass render options and block to calls to #render_in
94926db 
Closes [rails#45432][]

Support for objects that respond to `#render_in` was introduced in
[rails#36388][] and [rails#37919][]. Those implementations assume that the
instance will all the context it needs to render itself. That assumption
doesn't account for call-site arguments like `locals: { ... }` or a
block.

This commit expands support for rendering with a `:renderable` option to
incorporate locals and blocks. For example:

```ruby
class Greeting
  def render_in(view_context, **options, &block)
    if block
      view_context.render plain: block.call
    else
      case Array(options[:formats]).first
      when :json
        view_context.render json: { greeting: "Hello, World!" }
      else
        view_context.render **options, inline: "<%= Hello, <%= name %>!"
      end
    end
  end

  def format
    :html
  end
end

render(Greeting.new)                              # => "Hello, World!"
render(Greeting.new, name: "Local")               # => "Hello, Local!"
render(Greeting.new) { "Hello, Block!" }          # => "Hello, Block!"

render(renderable: Greeting.new, formats: :json)  # => "{\"greeting\":\"Hello, World!\"}"
```

Since existing tools depend on the `#render_in(view_context)` signature
without options, this commit deprecates that signature in favor of one
that accepts options and a block.

[rails#45432]: rails#45432
[rails#36388]: rails#36388
[rails#37919]: rails#37919
seanpdoyle added a commit to seanpdoyle/rails that referenced this pull request Mar 2, 2024
@seanpdoyle
Pass render options and block to calls to #render_in
1c1918c 
Closes [rails#45432][]

Support for objects that respond to `#render_in` was introduced in
[rails#36388][] and [rails#37919][]. Those implementations assume that the
instance will all the context it needs to render itself. That assumption
doesn't account for call-site arguments like `locals: { ... }` or a
block.

This commit expands support for rendering with a `:renderable` option to
incorporate locals and blocks. For example:

```ruby
class Greeting
  def render_in(view_context, **options, &block)
    if block
      view_context.render plain: block.call
    else
      case Array(options[:formats]).first
      when :json
        view_context.render json: { greeting: "Hello, World!" }
      else
        view_context.render **options, inline: "<%= Hello, <%= name %>!"
      end
    end
  end

  def format
    :html
  end
end

render(Greeting.new)                              # => "Hello, World!"
render(Greeting.new, name: "Local")               # => "Hello, Local!"
render(Greeting.new) { "Hello, Block!" }          # => "Hello, Block!"

render(renderable: Greeting.new, formats: :json)  # => "{\"greeting\":\"Hello, World!\"}"
```

Since existing tools depend on the `#render_in(view_context)` signature
without options, this commit deprecates that signature in favor of one
that accepts options and a block.

[rails#45432]: rails#45432
[rails#36388]: rails#36388
[rails#37919]: rails#37919
seanpdoyle added a commit to seanpdoyle/rails that referenced this pull request Mar 2, 2024
@seanpdoyle
Pass render options and block to calls to #render_in
cbde368 
Closes [rails#45432][]

Support for objects that respond to `#render_in` was introduced in
[rails#36388][] and [rails#37919][]. Those implementations assume that the
instance will all the context it needs to render itself. That assumption
doesn't account for call-site arguments like `locals: { ... }` or a
block.

This commit expands support for rendering with a `:renderable` option to
incorporate locals and blocks. For example:

```ruby
class Greeting
  def render_in(view_context, **options, &block)
    if block
      view_context.render plain: block.call
    else
      case Array(options[:formats]).first
      when :json
        view_context.render json: { greeting: "Hello, World!" }
      else
        view_context.render **options, inline: "<%= Hello, <%= name %>!"
      end
    end
  end

  def format
    :html
  end
end

render(Greeting.new)                              # => "Hello, World!"
render(Greeting.new, name: "Local")               # => "Hello, Local!"
render(Greeting.new) { "Hello, Block!" }          # => "Hello, Block!"

render(renderable: Greeting.new, formats: :json)  # => "{\"greeting\":\"Hello, World!\"}"
```

Since existing tools depend on the `#render_in(view_context)` signature
without options, this commit deprecates that signature in favor of one
that accepts options and a block.

[rails#45432]: rails#45432
[rails#36388]: rails#36388
[rails#37919]: rails#37919
seanpdoyle added a commit to seanpdoyle/rails that referenced this pull request Mar 7, 2024
@seanpdoyle
Pass render options and block to calls to #render_in
465e84a 
Closes [rails#45432][]

Support for objects that respond to `#render_in` was introduced in
[rails#36388][] and [rails#37919][]. Those implementations assume that the
instance will all the context it needs to render itself. That assumption
doesn't account for call-site arguments like `locals: { ... }` or a
block.

This commit expands support for rendering with a `:renderable` option to
incorporate locals and blocks. For example:

```ruby
class Greeting
  def render_in(view_context, **options, &block)
    if block
      view_context.render plain: block.call
    else
      case Array(options[:formats]).first
      when :json
        view_context.render json: { greeting: "Hello, World!" }
      else
        view_context.render **options, inline: "<%= Hello, <%= name %>!"
      end
    end
  end

  def format
    :html
  end
end

render(Greeting.new)                              # => "Hello, World!"
render(Greeting.new, name: "Local")               # => "Hello, Local!"
render(Greeting.new) { "Hello, Block!" }          # => "Hello, Block!"

render(renderable: Greeting.new, formats: :json)  # => "{\"greeting\":\"Hello, World!\"}"
```

Since existing tools depend on the `#render_in(view_context)` signature
without options, this commit deprecates that signature in favor of one
that accepts options and a block.

[rails#45432]: rails#45432
[rails#36388]: rails#36388
[rails#37919]: rails#37919
seanpdoyle added a commit to seanpdoyle/rails that referenced this pull request Mar 8, 2024
@seanpdoyle
Pass render options and block to calls to #render_in
98f1705 
Closes [rails#45432][]

Support for objects that respond to `#render_in` was introduced in
[rails#36388][] and [rails#37919][]. Those implementations assume that the
instance will all the context it needs to render itself. That assumption
doesn't account for call-site arguments like `locals: { ... }` or a
block.

This commit expands support for rendering with a `:renderable` option to
incorporate locals and blocks. For example:

```ruby
class Greeting
  def render_in(view_context, **options, &block)
    if block
      view_context.render plain: block.call
    else
      case Array(options[:formats]).first
      when :json
        view_context.render json: { greeting: "Hello, World!" }
      else
        view_context.render **options, inline: "<%= Hello, <%= name %>!"
      end
    end
  end

  def format
    :html
  end
end

render(Greeting.new)                              # => "Hello, World!"
render(Greeting.new, name: "Local")               # => "Hello, Local!"
render(Greeting.new) { "Hello, Block!" }          # => "Hello, Block!"

render(renderable: Greeting.new, formats: :json)  # => "{\"greeting\":\"Hello, World!\"}"
```

Since existing tools depend on the `#render_in(view_context)` signature
without options, this commit deprecates that signature in favor of one
that accepts options and a block.

[rails#45432]: rails#45432
[rails#36388]: rails#36388
[rails#37919]: rails#37919
seanpdoyle added a commit to seanpdoyle/rails that referenced this pull request Mar 24, 2024
@seanpdoyle
Pass render options and block to calls to #render_in
56a1e49 
Closes [rails#45432][]

Support for objects that respond to `#render_in` was introduced in
[rails#36388][] and [rails#37919][]. Those implementations assume that the
instance will all the context it needs to render itself. That assumption
doesn't account for call-site arguments like `locals: { ... }` or a
block.

This commit expands support for rendering with a `:renderable` option to
incorporate locals and blocks. For example:

```ruby
class Greeting
  def render_in(view_context, **options, &block)
    if block
      view_context.render plain: block.call
    else
      case Array(options[:formats]).first
      when :json
        view_context.render json: { greeting: "Hello, World!" }
      else
        view_context.render **options, inline: "<%= Hello, <%= name %>!"
      end
    end
  end

  def format
    :html
  end
end

render(Greeting.new)                              # => "Hello, World!"
render(Greeting.new, name: "Local")               # => "Hello, Local!"
render(Greeting.new) { "Hello, Block!" }          # => "Hello, Block!"

render(renderable: Greeting.new, formats: :json)  # => "{\"greeting\":\"Hello, World!\"}"
```

Since existing tools depend on the `#render_in(view_context)` signature
without options, this commit deprecates that signature in favor of one
that accepts options and a block.

[rails#45432]: rails#45432
[rails#36388]: rails#36388
[rails#37919]: rails#37919
seanpdoyle added a commit to seanpdoyle/rails that referenced this pull request Apr 5, 2024
@seanpdoyle
Pass render options and block to calls to #render_in
97a7a97 
Closes [rails#45432][]

Support for objects that respond to `#render_in` was introduced in
[rails#36388][] and [rails#37919][]. Those implementations assume that the
instance will all the context it needs to render itself. That assumption
doesn't account for call-site arguments like `locals: { ... }` or a
block.

This commit expands support for rendering with a `:renderable` option to
incorporate locals and blocks. For example:

```ruby
class Greeting
  def render_in(view_context, **options, &block)
    if block
      view_context.render plain: block.call
    else
      case Array(options[:formats]).first
      when :json
        view_context.render json: { greeting: "Hello, World!" }
      else
        view_context.render **options, inline: "<%= Hello, <%= name %>!"
      end
    end
  end

  def format
    :html
  end
end

render(Greeting.new)                              # => "Hello, World!"
render(Greeting.new, name: "Local")               # => "Hello, Local!"
render(Greeting.new) { "Hello, Block!" }          # => "Hello, Block!"

render(renderable: Greeting.new, formats: :json)  # => "{\"greeting\":\"Hello, World!\"}"
```

Since existing tools depend on the `#render_in(view_context)` signature
without options, this commit deprecates that signature in favor of one
that accepts options and a block.

[rails#45432]: rails#45432
[rails#36388]: rails#36388
[rails#37919]: rails#37919
seanpdoyle added a commit to seanpdoyle/rails that referenced this pull request Apr 18, 2024
@seanpdoyle
Pass render options and block to calls to #render_in
c2f265e 
Closes [rails#45432][]

Support for objects that respond to `#render_in` was introduced in
[rails#36388][] and [rails#37919][]. Those implementations assume that the
instance will all the context it needs to render itself. That assumption
doesn't account for call-site arguments like `locals: { ... }` or a
block.

This commit expands support for rendering with a `:renderable` option to
incorporate locals and blocks. For example:

```ruby
class Greeting
  def render_in(view_context, **options, &block)
    if block
      view_context.render plain: block.call
    else
      case Array(options[:formats]).first
      when :json
        view_context.render json: { greeting: "Hello, World!" }
      else
        view_context.render **options, inline: "<%= Hello, <%= name %>!"
      end
    end
  end

  def format
    :html
  end
end

render(Greeting.new)                              # => "Hello, World!"
render(Greeting.new, name: "Local")               # => "Hello, Local!"
render(Greeting.new) { "Hello, Block!" }          # => "Hello, Block!"

render(renderable: Greeting.new, formats: :json)  # => "{\"greeting\":\"Hello, World!\"}"
```

Since existing tools depend on the `#render_in(view_context)` signature
without options, this commit deprecates that signature in favor of one
that accepts options and a block.

[rails#45432]: rails#45432
[rails#36388]: rails#36388
[rails#37919]: rails#37919
seanpdoyle added a commit to seanpdoyle/rails that referenced this pull request Apr 18, 2024
@seanpdoyle
Pass render options and block to calls to #render_in
77867f2 
Closes [rails#45432][]

Support for objects that respond to `#render_in` was introduced in
[rails#36388][] and [rails#37919][]. Those implementations assume that the
instance will all the context it needs to render itself. That assumption
doesn't account for call-site arguments like `locals: { ... }` or a
block.

This commit expands support for rendering with a `:renderable` option to
incorporate locals and blocks. For example:

```ruby
class Greeting
  def render_in(view_context, **options, &block)
    if block
      view_context.render plain: block.call
    else
      case Array(options[:formats]).first
      when :json
        view_context.render json: { greeting: "Hello, World!" }
      else
        view_context.render **options, inline: "<%= Hello, <%= name %>!"
      end
    end
  end

  def format
    :html
  end
end

render(Greeting.new)                              # => "Hello, World!"
render(Greeting.new, name: "Local")               # => "Hello, Local!"
render(Greeting.new) { "Hello, Block!" }          # => "Hello, Block!"

render(renderable: Greeting.new, formats: :json)  # => "{\"greeting\":\"Hello, World!\"}"
```

Since existing tools depend on the `#render_in(view_context)` signature
without options, this commit deprecates that signature in favor of one
that accepts options and a block.

[rails#45432]: rails#45432
[rails#36388]: rails#36388
[rails#37919]: rails#37919
seanpdoyle added a commit to seanpdoyle/rails that referenced this pull request Apr 24, 2024
@seanpdoyle
Pass render options and block to calls to #render_in
cd57c45 
Closes [rails#45432][]

Support for objects that respond to `#render_in` was introduced in
[rails#36388][] and [rails#37919][]. Those implementations assume that the
instance will all the context it needs to render itself. That assumption
doesn't account for call-site arguments like `locals: { ... }` or a
block.

This commit expands support for rendering with a `:renderable` option to
incorporate locals and blocks. For example:

```ruby
class Greeting
  def render_in(view_context, **options, &block)
    if block
      view_context.render plain: block.call
    else
      case Array(options[:formats]).first
      when :json
        view_context.render json: { greeting: "Hello, World!" }
      else
        view_context.render **options, inline: "<%= Hello, <%= name %>!"
      end
    end
  end

  def format
    :html
  end
end

render(Greeting.new)                              # => "Hello, World!"
render(Greeting.new, name: "Local")               # => "Hello, Local!"
render(Greeting.new) { "Hello, Block!" }          # => "Hello, Block!"

render(renderable: Greeting.new, formats: :json)  # => "{\"greeting\":\"Hello, World!\"}"
```

Since existing tools depend on the `#render_in(view_context)` signature
without options, this commit deprecates that signature in favor of one
that accepts options and a block.

[rails#45432]: rails#45432
[rails#36388]: rails#36388
[rails#37919]: rails#37919
seanpdoyle added a commit to seanpdoyle/rails that referenced this pull request May 15, 2024
@seanpdoyle
Pass render options and block to calls to #render_in
3b2546e 
Closes [rails#45432][]

Support for objects that respond to `#render_in` was introduced in
[rails#36388][] and [rails#37919][]. Those implementations assume that the
instance will all the context it needs to render itself. That assumption
doesn't account for call-site arguments like `locals: { ... }` or a
block.

This commit expands support for rendering with a `:renderable` option to
incorporate locals and blocks. For example:

```ruby
class Greeting
  def render_in(view_context, **options, &block)
    if block
      view_context.render plain: block.call
    else
      case Array(options[:formats]).first
      when :json
        view_context.render json: { greeting: "Hello, World!" }
      else
        view_context.render **options, inline: "<%= Hello, <%= name %>!"
      end
    end
  end

  def format
    :html
  end
end

render(Greeting.new)                              # => "Hello, World!"
render(Greeting.new, name: "Local")               # => "Hello, Local!"
render(Greeting.new) { "Hello, Block!" }          # => "Hello, Block!"

render(renderable: Greeting.new, formats: :json)  # => "{\"greeting\":\"Hello, World!\"}"
```

Since existing tools depend on the `#render_in(view_context)` signature
without options, this commit deprecates that signature in favor of one
that accepts options and a block.

[rails#45432]: rails#45432
[rails#36388]: rails#36388
[rails#37919]: rails#37919
seanpdoyle added a commit to seanpdoyle/rails that referenced this pull request May 16, 2024
@seanpdoyle
Pass render options and block to calls to #render_in
7f2d39e 
Closes [rails#45432][]

Support for objects that respond to `#render_in` was introduced in
[rails#36388][] and [rails#37919][]. Those implementations assume that the
instance will all the context it needs to render itself. That assumption
doesn't account for call-site arguments like `locals: { ... }` or a
block.

This commit expands support for rendering with a `:renderable` option to
incorporate locals and blocks. For example:

```ruby
class Greeting
  def render_in(view_context, **options, &block)
    if block
      view_context.render plain: block.call
    else
      case Array(options[:formats]).first
      when :json
        view_context.render json: { greeting: "Hello, World!" }
      else
        view_context.render **options, inline: "<%= Hello, <%= name %>!"
      end
    end
  end

  def format
    :html
  end
end

render(Greeting.new)                              # => "Hello, World!"
render(Greeting.new, name: "Local")               # => "Hello, Local!"
render(Greeting.new) { "Hello, Block!" }          # => "Hello, Block!"

render(renderable: Greeting.new, formats: :json)  # => "{\"greeting\":\"Hello, World!\"}"
```

Since existing tools depend on the `#render_in(view_context)` signature
without options, this commit deprecates that signature in favor of one
that accepts options and a block.

[rails#45432]: rails#45432
[rails#36388]: rails#36388
[rails#37919]: rails#37919
seanpdoyle added a commit to seanpdoyle/rails that referenced this pull request Jul 13, 2024
@seanpdoyle
Pass render options and block to calls to #render_in
dbed3b1 
Closes [rails#45432][]

Support for objects that respond to `#render_in` was introduced in
[rails#36388][] and [rails#37919][]. Those implementations assume that the
instance will all the context it needs to render itself. That assumption
doesn't account for call-site arguments like `locals: { ... }` or a
block.

This commit expands support for rendering with a `:renderable` option to
incorporate locals and blocks. For example:

```ruby
class Greeting
  def render_in(view_context, **options, &block)
    if block
      view_context.render plain: block.call
    else
      case Array(options[:formats]).first
      when :json
        view_context.render json: { greeting: "Hello, World!" }
      else
        view_context.render **options, inline: "<%= Hello, <%= name %>!"
      end
    end
  end

  def format
    :html
  end
end

render(Greeting.new)                              # => "Hello, World!"
render(Greeting.new, name: "Local")               # => "Hello, Local!"
render(Greeting.new) { "Hello, Block!" }          # => "Hello, Block!"

render(renderable: Greeting.new, formats: :json)  # => "{\"greeting\":\"Hello, World!\"}"
```

Since existing tools depend on the `#render_in(view_context)` signature
without options, this commit deprecates that signature in favor of one
that accepts options and a block.

[rails#45432]: rails#45432
[rails#36388]: rails#36388
[rails#37919]: rails#37919
seanpdoyle added a commit to seanpdoyle/rails that referenced this pull request Aug 2, 2024
@seanpdoyle
Pass render options and block to calls to #render_in
4c26fcd 
Closes [rails#45432][]

Support for objects that respond to `#render_in` was introduced in
[rails#36388][] and [rails#37919][]. Those implementations assume that the
instance will all the context it needs to render itself. That assumption
doesn't account for call-site arguments like `locals: { ... }` or a
block.

This commit expands support for rendering with a `:renderable` option to
incorporate locals and blocks. For example:

```ruby
class Greeting
  def render_in(view_context, **options, &block)
    if block
      view_context.render plain: block.call
    else
      case Array(options[:formats]).first
      when :json
        view_context.render json: { greeting: "Hello, World!" }
      else
        view_context.render **options, inline: "<%= Hello, <%= name %>!"
      end
    end
  end

  def format
    :html
  end
end

render(Greeting.new)                              # => "Hello, World!"
render(Greeting.new, name: "Local")               # => "Hello, Local!"
render(Greeting.new) { "Hello, Block!" }          # => "Hello, Block!"

render(renderable: Greeting.new, formats: :json)  # => "{\"greeting\":\"Hello, World!\"}"
```

Since existing tools depend on the `#render_in(view_context)` signature
without options, this commit deprecates that signature in favor of one
that accepts options and a block.

[rails#45432]: rails#45432
[rails#36388]: rails#36388
[rails#37919]: rails#37919
seanpdoyle added a commit to seanpdoyle/rails that referenced this pull request Sep 28, 2024
@seanpdoyle
Pass render options and block to calls to #render_in
a92e0e8 
Closes [rails#45432][]

Support for objects that respond to `#render_in` was introduced in
[rails#36388][] and [rails#37919][]. Those implementations assume that the
instance will all the context it needs to render itself. That assumption
doesn't account for call-site arguments like `locals: { ... }` or a
block.

This commit expands support for rendering with a `:renderable` option to
incorporate locals and blocks. For example:

```ruby
class Greeting
  def render_in(view_context, **options, &block)
    if block
      view_context.render plain: block.call
    else
      case Array(options[:formats]).first
      when :json
        view_context.render json: { greeting: "Hello, World!" }
      else
        view_context.render **options, inline: "<%= Hello, <%= name %>!"
      end
    end
  end

  def format
    :html
  end
end

render(Greeting.new)                              # => "Hello, World!"
render(Greeting.new, name: "Local")               # => "Hello, Local!"
render(Greeting.new) { "Hello, Block!" }          # => "Hello, Block!"

render(renderable: Greeting.new, formats: :json)  # => "{\"greeting\":\"Hello, World!\"}"
```

Since existing tools depend on the `#render_in(view_context)` signature
without options, this commit deprecates that signature in favor of one
that accepts options and a block.

[rails#45432]: rails#45432
[rails#36388]: rails#36388
[rails#37919]: rails#37919
seanpdoyle added a commit to seanpdoyle/rails that referenced this pull request Oct 4, 2024
@seanpdoyle
Pass render options and block to calls to #render_in
33d6dad 
Closes [rails#45432][]

Support for objects that respond to `#render_in` was introduced in
[rails#36388][] and [rails#37919][]. Those implementations assume that the
instance will all the context it needs to render itself. That assumption
doesn't account for call-site arguments like `locals: { ... }` or a
block.

This commit expands support for rendering with a `:renderable` option to
incorporate locals and blocks. For example:

```ruby
class Greeting
  def render_in(view_context, **options, &block)
    if block
      view_context.render plain: block.call
    else
      case Array(options[:formats]).first
      when :json
        view_context.render json: { greeting: "Hello, World!" }
      else
        view_context.render **options, inline: "<%= Hello, <%= name %>!"
      end
    end
  end

  def format
    :html
  end
end

render(Greeting.new)                              # => "Hello, World!"
render(Greeting.new, name: "Local")               # => "Hello, Local!"
render(Greeting.new) { "Hello, Block!" }          # => "Hello, Block!"

render(renderable: Greeting.new, formats: :json)  # => "{\"greeting\":\"Hello, World!\"}"
```

Since existing tools depend on the `#render_in(view_context)` signature
without options, this commit deprecates that signature in favor of one
that accepts options and a block.

[rails#45432]: rails#45432
[rails#36388]: rails#36388
[rails#37919]: rails#37919
seanpdoyle added a commit to seanpdoyle/rails that referenced this pull request Dec 18, 2024
@seanpdoyle
Pass render options and block to calls to #render_in
1ea1ac5 
Closes [rails#45432][]

Support for objects that respond to `#render_in` was introduced in
[rails#36388][] and [rails#37919][]. Those implementations assume that the
instance will all the context it needs to render itself. That assumption
doesn't account for call-site arguments like `locals: { ... }` or a
block.

This commit expands support for rendering with a `:renderable` option to
incorporate locals and blocks. For example:

```ruby
class Greeting
  def render_in(view_context, **)
    if block_given?
      view_context.render(html: yield)
    else
      view_context.render(inline: <<~ERB.strip, **)
        Hello, <%= name %>
      ERB
    end
  end
end

render(Greeting.new)                    # => "Hello, World"
render(Greeting.new, name: "Local")     # => "Hello, Local"
render(Greeting.new) { "Hello, Block" } # => "Hello, Block"
```

Since existing tools depend on the `#render_in(view_context)` signature
without options, this commit deprecates that signature in favor of one
that accepts options and a block.

[rails#45432]: rails#45432
[rails#36388]: rails#36388
[rails#37919]: rails#37919
seanpdoyle added a commit to seanpdoyle/rails that referenced this pull request Jan 17, 2025
@seanpdoyle
Pass render options and block to calls to #render_in
50c601b 
Closes [rails#45432][]

Support for objects that respond to `#render_in` was introduced in
[rails#36388][] and [rails#37919][]. Those implementations assume that the
instance will all the context it needs to render itself. That assumption
doesn't account for call-site arguments like `locals: { ... }` or a
block.

This commit expands support for rendering with a `:renderable` option to
incorporate locals and blocks. For example:

```ruby
class Greeting
  def render_in(view_context, **)
    if block_given?
      view_context.render(html: yield)
    else
      view_context.render(inline: <<~ERB.strip, **)
        Hello, <%= name %>
      ERB
    end
  end
end

render(Greeting.new)                    # => "Hello, World"
render(Greeting.new, name: "Local")     # => "Hello, Local"
render(Greeting.new) { "Hello, Block" } # => "Hello, Block"
```

Since existing tools depend on the `#render_in(view_context)` signature
without options, this commit deprecates that signature in favor of one
that accepts options and a block.

[rails#45432]: rails#45432
[rails#36388]: rails#36388
[rails#37919]: rails#37919
seanpdoyle added a commit to seanpdoyle/rails that referenced this pull request Jul 16, 2025
@seanpdoyle
Pass render options and block to calls to #render_in
fdc3103 
Closes [rails#45432][]

Support for objects that respond to `#render_in` was introduced in
[rails#36388][] and [rails#37919][]. Those implementations assume that the
instance will all the context it needs to render itself. That assumption
doesn't account for call-site arguments like `locals: { ... }` or a
block.

This commit expands support for rendering with a `:renderable` option to
incorporate locals and blocks. For example:

```ruby
class Greeting
  def render_in(view_context, **)
    if block_given?
      view_context.render(html: yield)
    else
      view_context.render(inline: <<~ERB.strip, **)
        Hello, <%= name %>
      ERB
    end
  end
end

render(Greeting.new)                    # => "Hello, World"
render(Greeting.new, name: "Local")     # => "Hello, Local"
render(Greeting.new) { "Hello, Block" } # => "Hello, Block"
```

Since existing tools depend on the `#render_in(view_context)` signature
without options, this commit deprecates that signature in favor of one
that accepts options and a block.

[rails#45432]: rails#45432
[rails#36388]: rails#36388
[rails#37919]: rails#37919
seanpdoyle added a commit to seanpdoyle/rails that referenced this pull request Jul 16, 2025
@seanpdoyle
Pass render options and block to calls to #render_in
7614159 
Closes [rails#45432][]

Support for objects that respond to `#render_in` was introduced in
[rails#36388][] and [rails#37919][]. Those implementations assume that the
instance will all the context it needs to render itself. That assumption
doesn't account for call-site arguments like `locals: { ... }` or a
block.

This commit expands support for rendering with a `:renderable` option to
incorporate locals and blocks. For example:

```ruby
class Greeting
  def render_in(view_context, **)
    if block_given?
      view_context.render(html: yield)
    else
      view_context.render(inline: <<~ERB.strip, **)
        Hello, <%= name %>
      ERB
    end
  end
end

render(Greeting.new)                    # => "Hello, World"
render(Greeting.new, name: "Local")     # => "Hello, Local"
render(Greeting.new) { "Hello, Block" } # => "Hello, Block"
```

Since existing tools depend on the `#render_in(view_context)` signature
without options, this commit deprecates that signature in favor of one
that accepts options and a block.

[rails#45432]: rails#45432
[rails#36388]: rails#36388
[rails#37919]: rails#37919
seanpdoyle added a commit to seanpdoyle/rails that referenced this pull request Jul 31, 2025
@seanpdoyle
Pass render options and block to calls to #render_in
15f9f6a 
Closes [rails#45432][]

Support for objects that respond to `#render_in` was introduced in
[rails#36388][] and [rails#37919][]. Those implementations assume that the
instance will all the context it needs to render itself. That assumption
doesn't account for call-site arguments like `locals: { ... }` or a
block.

This commit expands support for rendering with a `:renderable` option to
incorporate locals and blocks. For example:

```ruby
class Greeting
  def render_in(view_context, **)
    if block_given?
      view_context.render(html: yield)
    else
      view_context.render(inline: <<~ERB.strip, **)
        Hello, <%= name %>
      ERB
    end
  end
end

render(Greeting.new)                    # => "Hello, World"
render(Greeting.new, name: "Local")     # => "Hello, Local"
render(Greeting.new) { "Hello, Block" } # => "Hello, Block"
```

Since existing tools depend on the `#render_in(view_context)` signature
without options, this commit deprecates that signature in favor of one
that accepts options and a block.

[rails#45432]: rails#45432
[rails#36388]: rails#36388
[rails#37919]: rails#37919
seanpdoyle added a commit to seanpdoyle/rails that referenced this pull request Sep 19, 2025
@seanpdoyle
Pass render options and block to calls to #render_in
c3a7449 
Closes [rails#45432][]

Support for objects that respond to `#render_in` was introduced in
[rails#36388][] and [rails#37919][]. Those implementations assume that the
instance will all the context it needs to render itself. That assumption
doesn't account for call-site arguments like `locals: { ... }` or a
block.

This commit expands support for rendering with a `:renderable` option to
incorporate locals and blocks. For example:

```ruby
class Greeting
  def render_in(view_context, **)
    if block_given?
      view_context.render(html: yield)
    else
      view_context.render(inline: <<~ERB.strip, **)
        Hello, <%= name %>
      ERB
    end
  end
end

render(Greeting.new)                    # => "Hello, World"
render(Greeting.new, name: "Local")     # => "Hello, Local"
render(Greeting.new) { "Hello, Block" } # => "Hello, Block"
```

Since existing tools depend on the `#render_in(view_context)` signature
without options, this commit deprecates that signature in favor of one
that accepts options and a block.

[rails#45432]: rails#45432
[rails#36388]: rails#36388
[rails#37919]: rails#37919
seanpdoyle added a commit to seanpdoyle/rails that referenced this pull request Sep 19, 2025
@seanpdoyle
Pass render options and block to calls to #render_in
01c275b 
Closes [rails#45432][]

Support for objects that respond to `#render_in` was introduced in
[rails#36388][] and [rails#37919][]. Those implementations assume that the
instance will all the context it needs to render itself. That assumption
doesn't account for call-site arguments like `locals: { ... }` or a
block.

This commit expands support for rendering with a `:renderable` option to
incorporate locals and blocks. For example:

```ruby
class Greeting
  def render_in(view_context, **)
    if block_given?
      view_context.render(html: yield)
    else
      view_context.render(inline: <<~ERB.strip, **)
        Hello, <%= name %>
      ERB
    end
  end
end

render(Greeting.new)                    # => "Hello, World"
render(Greeting.new, name: "Local")     # => "Hello, Local"
render(Greeting.new) { "Hello, Block" } # => "Hello, Block"
```

Since existing tools depend on the `#render_in(view_context)` signature
without options, this commit deprecates that signature in favor of one
that accepts options and a block.

[rails#45432]: rails#45432
[rails#36388]: rails#36388
[rails#37919]: rails#37919
seanpdoyle added a commit to seanpdoyle/rails that referenced this pull request Oct 3, 2025
@seanpdoyle
Pass render options and block to calls to #render_in
7185a7e 
Closes [rails#45432][]

Support for objects that respond to `#render_in` was introduced in
[rails#36388][] and [rails#37919][]. Those implementations assume that the
instance will all the context it needs to render itself. That assumption
doesn't account for call-site arguments like `locals: { ... }` or a
block.

This commit expands support for rendering with a `:renderable` option to
incorporate locals and blocks. For example:

```ruby
class Greeting
  def render_in(view_context, **)
    if block_given?
      view_context.render(html: yield)
    else
      view_context.render(inline: <<~ERB.strip, **)
        Hello, <%= name %>
      ERB
    end
  end
end

render(Greeting.new)                    # => "Hello, World"
render(Greeting.new, name: "Local")     # => "Hello, Local"
render(Greeting.new) { "Hello, Block" } # => "Hello, Block"
```

Since existing tools depend on the `#render_in(view_context)` signature
without options, this commit deprecates that signature in favor of one
that accepts options and a block.

[rails#45432]: rails#45432
[rails#36388]: rails#36388
[rails#37919]: rails#37919
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

actionpack actionview

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@joelhawksley @eileencodes