- 🇺🇸United States Maeglin
The current time-based view caching implementation is useful, as long as it's understood what it does, which is setting the max age for query results and rendered output. Unfortunately, the labeling for those config options doesn't make that clear. Cached items might still be invalidated because underlying content has changed, but if you're not setting a minimum age then there's no harm done.
As for use cases for the way it currently works, I can think of two right away:
1) The "time ago" date/time field formatter that's built into the core. With only tag-based caching, you might see an update or creation time of "2 hours ago", which could actually be days ago if nothing has changed in that time.
2) A notification page that I recently built, with dynamic highlighting of messages posted in the last 24 hours. The highlighting is done in the Twig template so, if the rendered output is only refreshed when new notifications are posted, it could be stuck for days.
In both cases, tag-based invalidation is also desired, so that the views reflect changes to underlying content.
That's not to say that a min-age setting wouldn't be useful in some cases, but it should be in addition to (not instead of) a max-age setting.