citry-django-compressor

Routes Citry components' CSS and JS through django-compressor, so they are preprocessed, minified and served as compressed files.

Which package do I want?

It depends on who owns the page.

Citry owns the page. A view renders one component tree and Citry holds the whole page's deduplicated asset list, placing it through <c-css /> and <c-js />. This package takes that list and hands it to django-compressor. Use this package.

Django owns the page. Your <head> lives in a Django template and Citry renders <c-*> regions inside it, each collecting its own assets. citry-django's page is what brings those together, and this package bundles what it collected into one file per response. Say where with <c-css /> and <c-js /> in your base template. Use this package.

Setup

pip install citry-django-compressor

# myproject/citry_app.py
from citry import Citry
from citry_django import CitryDjangoExtension
from citry_django_compressor import CitryCompressorExtension

app = Citry(extensions=[CitryDjangoExtension(), CitryCompressorExtension()])

Components keep declaring assets the way Citry documents. Nothing else is added to a component.

What it does

At serialize time the extension takes the render's final, deduplicated asset lists, feeds them to django-compressor as one CSS group and one JS group, and replaces them with the compressed results. Citry's own runtime scripts are left alone: they are not yours to bundle.

Results come from django-compressor's cache where that is allowed, keyed the way the {% compress %} tag keys it, on a digest of the content plus the mtimes of its sources. Without that every render recompiles its SCSS from scratch.

Citry's dependency strategy

This package rewrites what Citry resolves, so CITRY_DEPS_STRATEGY, citry-django's setting for what gets serialized, decides what it can reach. Leave it at its default: on "ignore" Citry resolves nothing, there is nothing to compress, and a page loads without its component styles.

Settings

Everything is django-compressor's own configuration. There is no separate setting for whether to compress: COMPRESS_ENABLED decides, exactly as it does for the template tag.

# settings.py
COMPRESS_ENABLED = True
COMPRESS_PRECOMPILERS = (("text/x-scss", "django_libsass.SassCompiler"),)
STATICFILES_FINDERS = [..., "compressor.finders.CompressorFinder"]

A compressor class named in COMPRESSORS is used here too, the same one a {% compress %} block uses, so a project that names its output files its own way gets that for component assets as well.

There is no setting here at all. What compiles an asset is the asset's own type, written the way you would write it in a template:

class Dependencies:
    css = [Style(url=static("theme.scss"), attrs={"type": "text/x-scss"})]

django-compressor picks its precompiler on that attribute and nothing else, so a .scss that declares no type arrives as source and leaves as source, exactly as a <link href="x.scss"> without one would inside a {% compress %} block. The mimetype is an arbitrary string that has to match your COMPRESS_PRECOMPILERS entry exactly.

Options

force exists for output that depends on something the cache key cannot see. Wagtail's preview of unsaved theme settings is the case it was written for: the compiled CSS differs, the content and mtimes do not, so a cached entry would show the wrong thing.

CitryCompressorExtension(force=lambda: getattr(get_current_request(), "is_preview", False))

Limitations

Bundling a whole response needs somewhere to put the result, so a base template that writes no <c-css /> or <c-js /> gets one compressed file per <c-*> region instead: the assets stay where Citry put them, and putting a bundle somewhere you did not ask for it would be worse than not making one. Repeats are still dropped first, so a stylesheet two regions both asked for is compiled once either way.

License

MIT