View caching guide: fragment, collection, and HTTP caching in the modern Rails era

[topherfangio]

Goal

Add a view caching guide to the guides section covering how to cache views in the current Rails era — fragment / Russian-doll caching, collection caching, and HTTP/conditional caching — grounded in the defaults and realities this stack actually runs on (Solid Cache, Hotwire, ViewComponent), not the Redis-everywhere advice from a decade ago.

Belongs with the existing dev guides (Services, Authentication, Error Handling, …).

What the guide should cover

• Why now / the modern landscape — Solid Cache as the Rails 8 default cache store (database-backed, no separate Redis/Memcached to run), and the fact that server-rendered Hotwire apps push more HTML generation back to the server, which makes view caching matter again.
• Fragment & Russian-doll caching — the cache helper in views/templates, nesting caches, automatic invalidation via belongs_to …, touch: true, and cache_if / cache_unless.
• Collection caching — render partial:, collection:, cached: true (and render @items, cached: true) for list rendering: the single multi-key read, and the caveats (one template, no partial-local surprises).
• Cache keys & versioning — cache_key_with_version, recyclable cache keys, how updated_at drives invalidation, explicit dependency/version keys, and the template-tree digest that auto-busts a fragment when its template (or a nested one) changes.
• HTTP / conditional caching — fresh_when / stale?, ETags, and expires_in for cheap full-response skips via conditional GET.
• ViewComponent specifics — this stack is ViewComponent-based, so cover caching components: using cache inside a component template, component cache keys, and the known gotchas (slot/content blocks, digest tracking) so readers don't ship silently-stale component output.
• Turbo / Hotwire interplay — how fragment caches coexist with Turbo Frames / Streams and morphing, and caching lazy-loaded frames.
• Stores & config — Solid Cache vs. :memory_store / :redis_cache_store; toggling caching in development (just demo-cache / just demo-nocache, i.e. docs/demo/tmp/caching-dev.txt); namespacing and expiry.
• When not to cache — cheap-to-render views, highly personalized fragments, low reuse. Measure before reaching for it.

Living example

The demo already has a dev-caching toggle (just demo-cache → docs/demo/tmp/caching-dev.txt) but no fragment/collection caching in its views yet — a clean place to demonstrate the patterns end to end.

Acceptance

• New guide page under docs/demo/app/views/guides/, wired into the guides nav and following the established guide structure + visual house style.
• Reflects the modern defaults (Solid Cache, Hotwire, ViewComponent), not just generic "fragment caching 101."

🤖 Generated with Claude Code