Tuesday, 15 February 2011

Rails 4 fragment caching with stylesheet_link_tag -



Rails 4 fragment caching with stylesheet_link_tag -

rails 4 uses cache_digests (https://github.com/rails/cache_digests) assist fragment cache invalidation: cache_digests creates md5 hash of template , known dependencies, allowing fragment caches become invalidated assigning new key when template or dependency changes.

my question is: fragment cache wrapping stylesheet_link_tag invalidated if application.css file's md5 hash changes during rake assets:precompile? right in our header:

<% cache("header-cache-key") %> <%= stylesheet_link_tag "application" %> <%= javascript_include_tag "application" %> <% end %>

is safe? fear when css or js changes, application-xxxxxxx.css become application-yyyyyyy.css, our header cached old application-xxxxxxx.css. if application-xxxxxxx.css gone public/assets, result in ugly page.

no cache wont busted/invalidated on changes compiled css/js.

the way rails busts cache on code alter done inserting file's hash view's cache key.

e.g have view file @ app/views/layouts/application.html.erb. rails generates hash file's content (i.e html/ruby code, not executed output). let's pretend hash generated 'abdefg123'.

if application.html.erb has next cache code:

<% cache("header-cache-key") %> <%= stylesheet_link_tag "application" %> <%= javascript_include_tag "application" %> <% end %>

the actual cache key generated along of lines "views/layouts/application-abcdefg123/header-cache-key".

as alter in compiled css/js doesn't alter ruby/html in file, computed hash layout code doesn't alter , hence cache key 'header-cache-key' same, meaning cache isn't busted.

ruby-on-rails caching ruby-on-rails-4 memcached sprockets

No comments:

Post a Comment