torchbox / torchbox/django-pattern-library
Add a no-op cache tag
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 423
- Forks
- 53
- PR merge metrics
- No merged PRs in 30d
Description
Is your proposal related to a problem?
Cache-related template tag's like Django's {% cache %} and Wagtail's {% wagtailcache %} and {% wagtailpagecache %} work by attempting to render a cached fragment, falling back to rendering the child nodes and storing the result in the cache.
When viewing patterns in the pattern library, particularly during local development, this is not what you want. You want to be able to instantly view changes made to the template. Additionally, context required to generate cache keys, such as page.cache_key in the case of {% wagtailpagecache %} may not be present in the pattern library context.
Describe the solution you'd like
I propose the DPL should have a no-op tag that unconditionally renders it's children and the ability to specify by name the tags that should be replaced with the no-op tag implementation in pattern library contexts. Config for this might look something like the following:
PATTERN_LIBRARY = {
...,
"NOOP_CACHE_TAG_NAMES": ["cache", "wagtailcache", "wagtailpagecache"],
}
Maybe ["cache"] should be the default value for this?
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing how pattern library contexts render Django template tags and where PATTERN_LIBRARY configuration is read. Focus on the existing cache-related tag handling and the proposed NOOP_CACHE_TAG_NAMES setting. Done means configured cache tags render their children without cache access in pattern library contexts, with the default behavior and configuration documented or tested.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- django, python
- Domain
- backend, tooling
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100