Templates only have one format. Before this commit, templates would be
constructed with a single element array that contained the format. This
commit eliminates the single element array and just implements a
`format` method. This saves one array allocation per template.
This commit introduces "rendered template" and "rendered collection"
objects. The template renderers can now return a more complex object
than just strings. This allows the framework to get more information
about the templates that were rendered. In this commit we use the
rendered template object to set the "rendered_format" on the lookup
context in the controller rather than all the way in the template renderer.
That means we don't need to check the "rendered_format" every time we
render a template, we just do it once after all templates have been
rendered.
This reduces the surface area of our API and removes a Liskov issue.
Both TemplateRenderer and PartialRenderer inherit from AbstractRenderer,
but since PartialRenderer implements it's own `find_template` that is
private, and has the wrong method signature, an instance of
PartialRenderer cannot be substituted for an instance of
AbstractRenderer renderer. Removing the superclass implementation
solves both issues.
1. Conceptually revert #20276
The feature was implemented for the `responders` gem. In the end,
they did not need that feature, and have found a better fix (see
plataformatec/responders#131).
`ImplicitRender` is the place where Rails specifies our default
policies for the case where the user did not explicitly tell us
what to render, essentially describing a set of heuristics. If
the gem (or the user) knows exactly what they want, they could
just perform the correct `render` to avoid falling through to
here, as `responders` did (the user called `respond_with`).
Reverting the patch allows us to avoid exploding the complexity
and defining “the fallback for a fallback” policies.
2. `respond_to` and templates are considered exhaustive enumerations
If the user specified a list of formats/variants in a `respond_to`
block, anything that is not explicitly included should result
in an `UnknownFormat` error (which is then caught upstream to
mean “406 Not Acceptable” by default). This is already how it
works before this commit.
Same goes for templates – if the user defined a set of templates
(usually in the file system), that set is now considered exhaustive,
which means that “missing” templates are considered `UnknownFormat`
errors (406).
3. To keep API endpoints simple, the implicit render behavior for
actions with no templates defined at all (regardless of formats,
locales, variants, etc) are defaulted to “204 No Content”. This
is a strictly narrower version of the feature landed in #19036 and
#19377.
4. To avoid confusion when interacting in the browser, these actions
will raise an `UnknownFormat` error for “interactive” requests
instead. (The precise definition of “interactive” requests might
change – the spirit here is to give helpful messages and avoid
confusions.)
Closes#20666, #23062, #23077, #23564
[Godfrey Chan, Jon Moss, Kasper Timm Hansen, Mike Clark, Matthew Draper]
Augments the collection caching with some instrumentation that's logged.
For collections that have been cached like:
```ruby
<%= render partial: 'notifications/notification', collection: @notifications, cached: true %>
```
We'll output a line showing how many cache hits we had when rendering it:
```
Rendered collection of notifications/_notification.html.erb [0 / 100 cache hits] (3396.5ms)
```
