Проблемы, связанные с кэшированием русской куклы с наследованием шаблонов

Question

Я использую и Template Inheritance, и Russian Doll Caching (используя гем cache_digests) независимо друг от друга в отдельных частях довольно сложного Rails-приложения с большим успехом.

Я испытываю трудности при совместном использовании двух технологий, что заставляет меня подозревать, что я могу делать что-то не так...

Для очень простого примера рассмотрим приложение, состоящее из двух контроллеров, ThingOnes и ThingTwos. Это приложение имеет один макет (layouts/application.html.erb) который просто отображает заголовочный файл с: <%= render 'header' %>,

По умолчанию Rails будет искать эту часть в нескольких местах, включая каталог представления для макета (views/application/_header.html.erb), а также любой специфический для текущего контроллера (например, views/thing_ones/_header.html.erb или же views/thing_twos/_header.html.erb). Это означает, что для целей кэширования у меня в основном есть список зависимостей шаблона (не считая движков или чего-либо еще), например:

[
  "application/header",
  "thing_ones/header",
  "thing_twos/header"
]

Теперь мы обернем этот вызов рендеринга кэшированием следующим образом:

<% cache 'header' do %>
  <%= render 'header' %>
<% end %>

К сожалению, работает rake cache_digests:nested_dependencies TEMPLATE=layouts/application результаты в следующем списке зависимостей.

[
  "layouts/header"
]

Кажется, он не заботится о наследовании шаблонов вообще. Изменение файлов, не включенных в список, приводит к ожидаемому эффекту изменения файлов, не включенных в список, - срок действия кэша не истек и отображается устаревший заголовок.

Это можно легко исправить, указав соответствующие пути к шаблонам, например:

<% cache 'header' do %>
  <%# Template Dependency: application/header %>
  <%# Template Dependency: thing_ones/header %>
  <%# Template Dependency: thing_twos/header %>
  <%= render 'header' %>
<% end %>

Это похоже на очень плохое решение, так как оно не очень хорошо развивается и требует много легкомысленного оформления для кэширования вызовов, чтобы сохранить существующее поведение наследования шаблонов.

Точно так же можно более явно указать местоположение заголовка, например так:

<% cache 'header' do %>
  <%= render 'application/header' %>
<% end %>

Это также не позволяет сохранить существующее поведение наследования шаблонов, что делает его непригодным для наших нужд.

Последний вариант заключается в перемещении cache вызовите в заголовок партиалы сами. Это не только неэффективно, так как оставляет render вызов из кеша. Он также более ВЛАЖНЫЙ (напишите все дважды), чем СУХОЙ, что является значительным отключением.

Итак, чтобы перейти к моему актуальному вопросу (ям)... Я делаю это правильно? Это кажется довольно серьезным недостатком, который может повлиять на широкий спектр реализаций, но я не могу найти много дискуссий, связанных с этой конкретной проблемой, поэтому мне интересно, делают ли другие так, чтобы это работало лучше. Есть ли лучший способ сделать это, или, по крайней мере, автоматически указать полную иерархию зависимостей шаблона для частичного рендеринга?

Answer 1

Проблема здесь на самом деле в том, что вы предлагаете себе в конце: вы должны переместить cache метод в ваши представленные шаблоны.

Это может показаться большим количеством кода, но это необходимо для правильной работы дайджеста кеша. Кроме того, если ваши частичные (_header.html.erb в приложении thing_ones и thing_twos) различаются, если ключ кеша также будет другим. Это означает, что вы должны получить что-то вроде этого:

# layouts/application.html.erb
<%= render 'header' %>

# application/_header.html.erb 
<% cache 'application_header' do %>
  ...
<% end %>

# thing_ones/_header.html.erb
<% cache 'thing_ones_header' do %>
  ...
<% end %>

# and thing_twos/_header.html.erb
<% cache 'thing_twos_header' do %>
  ...
<% end %>

Без разных ключей кеша эти кеши перекрывают друг друга, что означает, что если, например. application/_header.html.erb сначала был кэширован, то это будет тот, который отображается один ThingOnes а также ThingTwos страницы.