Problem/Motivation
Back in #2318377: Determine whether a view is cacheable and its required contexts, store this i/t config entity we introduced a CachePluginInterface so that views plugin can specify which context their output/filtering is varied by.
CacheableDependencyInterface got introduced in the meantime which has the same feature, but instead of a boolean flag for cacheability
has a max-age.
Proposed resolution
Replace all usages and remove \Drupal\views\Plugin\CacheablePluginInterface
Remaining tasks
None.
User interface changes
None.
API changes
Yes: CachablePluginInterface is removed in favor of CacheableDependencyInterface.
Data model changes
Yes: config schema change.
Beta phase evaluation
| Issue category | Task because nothing is broken, nothing is new; we're just removing a one-off interface in favor of the standardized interface. | ||
|---|---|---|---|
| Issue priority | Major because Views using a one-off interface rather than the standardized makes the DX & learning curve more difficult than it has to be, with likely negative consequences for overall cacheability in the D8 ecosystem. | Prioritized changes | The main goal of this issue is cacheability/DX, and thus indirectly, perforamnce. |
| Disruption | Disruptive for core/contributed modules that provide Views handlers & plugins because it requires a BC break and a data model change (config schema change). The disruption is limited to the extent that (almost?) nobody has written Views handlers/plugins in D8 contrib yet. Finally, due to the bug #2538348: Config export UI exports entity properties that should not be exported, there is another aspect of disruption. Besides Views handlers/plugins, this also impacts default Views IF and ONLY IF they contain cacheability metadata; if they don't, they're not impacted; the cacheability metadata will be added automatically upon being imported/saved. |