| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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 commit passes the template format to the digestor in order to come
up with a key. Before this commit, the digestor would depend on the
side effect of the template renderer setting the rendered_format on the
lookup context. I would like to remove that mutation, so I've changed
this to pass the template format in to the digestor.
I've introduced a new instance variable that will be alive during a
template render. When the template is being rendered, it pushes the
current template on to a stack, setting `@current_template` to the
template currently being rendered. When the cache helper asks the
digestor for a key, it uses the format of the template currently on the
stack.
|
| |
|
|
| |
We can remove the ivar by caching the digest on the stack
|
| |
|
|
|
|
| |
This gets the PartialRenderer to be a bit closer to the
TemplateRenderer. TemplateRenderer already keeps its template in a
local variable.
|
| |
|
|
| |
Similar to 1853b0d0abf87dfdd4c3a277c3badb17ca19652e
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
On every iteration of generating a cache for a collection a “digest path” is calculated even though it’s exactly the same for every element.
This PR exposes a method `digest_path_from_virtual` that returns back a “digest_path”. This can in turn be passed back into `cache_fragment_name`. This not only does less work, but it also (you guessed it) uses less memory.
before: Total allocated: 762539 bytes (7035 objects)
after: Total allocated: 743590 bytes (6621 objects)
(762539 - 743590)/ 762539.0 # => 2.4% faster ⚡️⚡️
|
| | |
|
| |
|
|
|
| |
This reverts commit 3420a14590c0e6915d8b6c242887f74adb4120f9, reversing
changes made to afb66a5a598ce4ac74ad84b125a5abf046dcf5aa.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
```
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Having collection caching that wraps templates and automatically tries
to infer if they are cachable proved to be too much of a hassle.
We'd rather have it be something you explicitly turn on.
This removes much of the code and docs to explain the previous automatic
behavior.
This change also removes scoped cache keys and passing cache_options.
|
| |
|
|
|
|
|
| |
If the collection isn't empty any? will loop through it.
Spare the loop and be more concise with what we're asking the
collection about.
|
| |
|
|
|
|
| |
`PartialRenderer.render_collection_with/without_template` returns an array
of rendered partials. Avoid dup'ing and shifting it by indexing into
the collection instead.
|
| |
|
|
| |
Wasn't pulling its weight for a simple yield anymore.
|
| |
|
|
|
|
|
|
| |
Moves us closer to having access to a local template variable,
we can ask for eligibility and its virtual_path.
Currently we rely on `@template`, which we don't have available
when rendering collections without a fixed template.
|
| |
|
|
|
|
|
|
|
|
|
| |
A callable cache key writes to the collection cache under a certain namespace.
Which means if we don't have scoped cache key we can just rely on the
`cache model_name do` in the templates to cache them.
Less writes, more sharing.
Add `assert_customer_cached` to better illustrate this in tests, and remove
tests which then don't communicate as much.
|
| |
|
|
|
|
| |
`automatic_cache_eligible?´ is only called if there was no `:cache` key
to fetch in the `@options` via `cache_collection?`. So the check will
always be false.
|
| |
|
|
|
|
| |
Written when I didn't understand the internals as well. Action View
generally just refers to `@template` when meaning a fixed template
render. So follow that implicit convention.
|
| |
|
|
|
|
| |
We should only support a top level `cache_options`. We also don't
have to default the options to a hash as Active Support's cache
defaults that arg to nil.
|
| |
|
|
|
|
|
|
|
| |
Adds the `virtual_path` option to `cache_fragment_name` so it can
be provided when needed.
That allows `cache_collection_render` to get the appropriate cache
key with the digest generated based on the template and prevent
collision with other templates that cache the same collection.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Collections can take advantage of `multi_read` if they render one template
and their partials begin with a cache call.
The cache call must correspond to either what the collections elements are
rendered as, or match the inferred name of the partial.
So with a notifications/_notification.html.erb template like:
```ruby
<% cache notification %>
<%# ... %>
<% end %>
```
A collection would be able to use `multi_read` if rendered like:
```ruby
<%= render @notifications %>
<%= render partial: 'notifications/notification', collection: @notifications, as: :notification %>
```
|
|
|
Makes caching a collection of template partials faster using `read_multi`
on the Rails cache store.
Some caching implementations have optimized `read_multi` so we don't have
to check in the cache store for every template.
|
