Problem/Motivation
Similar to #2579941: Let Dynamic Page Cache warn developers when a controller's render array does not have #cache set we could force blocks to provide cache ability metadata.
Proposed resolution
Remaining tasks
User interface changes
API changes
Data model changes
Comment | File | Size | Author |
---|---|---|---|
#3 | 2584951-2.patch | 1002 bytes | dawehner |
Comments
Comment #2
BerdirBlock plugins have getCacheTags() and so on, why would they need to duplicate this on the render array they return?
Comment #3
dawehnerSomething like this would be quite a drastic API change.
Comment #4
Wim LeersYes it would.
It's also exactly why I always voiced concern about
. Because it makes it very easy to forget about cacheability, i.e. to not think about it.BlockBase
is an abominationhas an unfortunate architecture due to its unfortunate evolution. The exact same problem exists for access checks in blocks:… so… it tries to make things simple by implementing the actual method, and therefore actual block plugins (subclasses of
BlockBase
) are encouraged to implement/override thisblockAccess()
method.It's so very confusing.
Let's not add more of those.
(To truly understand the scope of the problem: try implementing a block plugin without using
BlockBase
. Really, try it. It makes you really understand the complexity.)Comment #5
dawehnerWell its a clear sign that assign the cachability metadata was too late in the cycle which made APIs partially really horrible.
No question, many of those APIs are bad.