Fragment caching in Ruby on Rails - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What does this fragment cache block output?

Consider this Rails view snippet using fragment caching:

<% cache('user_42_profile') do %>
  <p>User profile content</p>
<% end %>

What will be rendered on the page the first time and on subsequent requests?

Ruby on Rails

<% cache('user_42_profile') do %>
  <p>User profile content</p>
<% end %>

A First request renders the content and caches it; later requests render the cached content without re-executing the block.

B Every request renders the content and updates the cache with new content.

C The cache block is ignored and content is always rendered fresh.

D The cache block raises an error because the key is a string.

💡 Hint

Think about how fragment caching stores rendered HTML to speed up future requests.

Fragment caching stores the rendered HTML the first time the block runs. Later requests use the cached HTML directly, skipping the block.

📝 Syntax

intermediate

Identify the syntax error in this fragment cache usage

Which option contains a syntax error in using fragment caching in Rails views?

A <% cache(user) do %>Content<% end %>

B <% cache 'user' Content <% end %>

C <% cache 'user' do %>Content<% end %>

D <% cache user do %>Content<% end %>

💡 Hint

Look for missing 'do' or incorrect ERB tags.

Option B is missing the 'do' keyword and has incorrect ERB tag placement, causing a syntax error.

🔧 Debug

advanced

Why does this fragment cache not update after model change?

Given this code snippet:

<% cache(@post) do %>
  <p><%= @post.title %></p>
<% end %>

After updating @post.title in the database, the cached fragment still shows the old title. Why?

Ruby on Rails

<% cache(@post) do %>
  <p><%= @post.title %></p>
<% end %>

A Fragment caching does not work with instance variables.

B Rails caches the fragment forever by default, ignoring model changes.

C The cache block must be manually expired after updating the model.

D The cache key is based on @post's cache_key method, which did not change because the record was not saved properly.

💡 Hint

Check how Rails generates cache keys for Active Record objects.

Rails uses the model's cache_key, which includes timestamp. If the record was not saved or timestamp not updated, cache key stays same, so cache is reused.

🧠 Conceptual

advanced

What is the purpose of cache digests in fragment caching?

In Rails fragment caching, what role do cache digests play?

A They compress cached fragments to save space.

B They encrypt cached fragments for security.

C They track dependencies of partials to expire caches automatically when partials change.

D They store user session data inside cached fragments.

💡 Hint

Think about how Rails knows when to expire cached fragments if partial templates change.

Cache digests generate fingerprints of partial templates. When partials change, digests change, causing cache expiration automatically.

❓ state_output

expert

How many cached fragments exist after this code runs?

Given this Rails view code:

<% ['a', 'b', 'c'].each do |letter| %>
  <% cache("fragment_#{letter}") do %>
    <p>Letter: <%= letter %></p>
  <% end %>
<% end %>

After rendering once, how many separate cached fragments are stored?

Ruby on Rails

<% ['a', 'b', 'c'].each do |letter| %>
  <% cache("fragment_#{letter}") do %>
    <p>Letter: <%= letter %></p>
  <% end %>
<% end %>

A 3 cached fragments, one for each letter 'a', 'b', and 'c'.

B 1 cached fragment containing all letters combined.

C No cached fragments because cache keys are dynamic strings.

D 6 cached fragments due to internal Rails caching of partials.

💡 Hint

Each cache block with a unique key creates one fragment cache.

Each iteration caches a separate fragment with a unique key, so 3 fragments total.

Practice

1. What is the main purpose of fragment caching in Rails?

easy

A. To manage database connections efficiently

B. To store user login information securely

C. To save parts of a page so they load faster next time

D. To compress images for faster download

Solution

1. Step 1: Understand fragment caching concept

   Fragment caching stores parts of a webpage to avoid regenerating them every time.

2. Step 2: Identify the main benefit

   This speeds up page rendering by reusing cached parts instead of rebuilding them.

3. Final Answer:

   To save parts of a page so they load faster next time -> Option C

4. Quick Check:

   Fragment caching = save parts for speed [OK]

Hint: Fragment caching speeds up page parts loading [OK]

Common Mistakes:

• Confusing caching with user authentication
• Thinking it compresses images
• Assuming it manages database connections

2. Which of the following is the correct syntax to use fragment caching in a Rails view?

easy

A. <% cache 'unique_key' do %> ... <% end %>

B. <% cache do 'unique_key' %> ... <% end %>

C. <% cache 'unique_key' %> ... <% end %>

D. <% cache 'unique_key' { ... } %>

Solution

1. Step 1: Recall correct fragment caching syntax

   The correct syntax uses cache 'key' do ... end block in ERB.

2. Step 2: Check each option

   <% cache 'unique_key' do %> ... <% end %> matches the correct block form. Others have wrong block usage or missing do.

3. Final Answer:

   <% cache 'unique_key' do %> ... <% end %> -> Option A

4. Quick Check:

   Use cache 'key' do block [OK]

Hint: Remember: cache needs 'do' block syntax [OK]

Common Mistakes:

• Omitting the 'do' keyword
• Using braces {} instead of do...end in ERB
• Placing the key inside the block instead of as argument

3. Given this Rails view code:

<% cache 'post_1' do %>
  <h1>Post Title</h1>
  <p>Post content here.</p>
<% end %>

What happens if the post content changes but the cache is not expired?

medium

A. The page shows an error about stale cache

B. The page shows the old cached content, not the updated post

C. Rails automatically updates the cache with new content

D. The cache is ignored and content always updates

Solution

1. Step 1: Understand cache behavior on data change

   Fragment cache stores rendered content and does not update unless expired or cleared.

2. Step 2: Identify effect of not expiring cache

   If cache is not expired, Rails serves the old cached content even if data changed.

3. Final Answer:

   The page shows the old cached content, not the updated post -> Option B

4. Quick Check:

   Cache stale without expiry = old content shown [OK]

Hint: Cache must be expired to show updated content [OK]

Common Mistakes:

• Assuming cache auto-updates on data change
• Expecting an error when cache is stale
• Thinking cache is ignored automatically

4. You have this fragment cache in your view:

<% cache 'user_42_profile' do %>
  <p>User profile info</p>
<% end %>

But after updating user data, the cache still shows old info. What is the likely problem?

medium

A. The cache key 'user_42_profile' was not changed or expired after update

B. The cache block syntax is incorrect and causes failure

C. Rails does not support fragment caching for user profiles

D. The view template is missing the cache helper method

Solution

1. Step 1: Check cache key usage

   Cache keys must change or be expired to reflect updated data.

2. Step 2: Identify why old data shows

   If key stays same and cache not expired, old cached content remains visible.

3. Final Answer:

   The cache key 'user_42_profile' was not changed or expired after update -> Option A

4. Quick Check:

   Cache key unchanged = stale cache shown [OK]

Hint: Expire or change cache key after data updates [OK]

Common Mistakes:

• Assuming syntax error causes stale cache
• Believing Rails disables caching for certain views
• Forgetting to use cache helper in views

5. You want to cache a list of comments for a post, but each comment can be edited independently. Which approach best ensures cache updates correctly?

hard

A. Cache only the post content and ignore comments

B. Cache the entire comments list with a single static key

C. Do not use fragment caching for comments to avoid stale data

D. Cache each comment fragment separately using a unique key per comment

Solution

1. Step 1: Understand caching granularity

   When parts update independently, caching each part separately allows selective expiration.

2. Step 2: Apply to comments list

   Caching each comment with a unique key lets you expire only changed comments, keeping others cached.

3. Step 3: Evaluate other options

   Single static key caches whole list, causing stale data if one comment changes. Avoiding caching loses speed benefits.

4. Final Answer:

   Cache each comment fragment separately using a unique key per comment -> Option D

5. Quick Check:

   Separate keys for independent parts = correct caching [OK]

Hint: Cache parts with unique keys for independent updates [OK]

Common Mistakes:

• Caching entire list causing stale comments
• Skipping caching due to fear of stale data
• Ignoring comment updates in cache strategy