Crop Rails 4 fragments using stylesheet_link_tag

Question

Rails 4 uses cache_digests ( https://github.com/rails/cache_digests ) to help with fragment cache invalidation: cache_digests creates an MD5 hash of the template and all its known dependencies, which allows fragment caches to become invalid by assigning a new key when changing the template or its addiction.

My question is: will the stylesheet_link_tag fragment cache wrapper be invalid if the .css application MD5 hash file changes during rake assets:precompile ? Do it right now in our header:

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

It is safe? I fear that when CSS or JS changes, application-xxxxxxx.css will become application-yyyyyyy.css , but our header will be cached with the old application-xxxxxxx.css . Then, if application-xxxxxxx.css left public/assets , this will lead to an ugly page.

Answer 1

There is no cache that will not be overloaded / invalidated upon changes in compiled CSS / JS.

The Rails path breaks up into the cache when the code changes by inserting the hash of the file into the view cache key.

For example, you have a view file in app/views/layouts/application.html.erb . Rails generates a hash from the contents of the file (i.e. HTML / Ruby code, not the executed output). Suppose the generated hash is "abdefg123".

If application.html.erb has the following cache code:

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

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

Since modifying compiled CSS / JS does not actually change Ruby / HTML in the file, the calculated hash for the layout code does not change, and therefore the cache key for "key-cache-key" is the same, which means that the cache is not unloaded.