Question re how JinjaX interacts with Jinja2 pre-compiled templates (ModuleLoader)

[anentropic]

I have a Django project where we are pre-compiling the Jinja templates to minimise cold-start delays when running in AWS Lambda

i.e. we call env.compile_templates as a build step and then use Jinja ModuleLoader as the template loader pointing to the pre-compiled modules

my assumption is that this is the same as Jinja2 'caching' but is effectively pre-warming the cache

I want to introduce JinjaX to the project but I am a bit uncertain how it interacts with our existing Jinja machinery

This is quite similar to the comment here #30 (comment)

I can see that JinjaX caching involves serializing the component def to a dict of props f3c9361#diff-c89d0d43fde46ff29ff599a61650dc9c78e6d1772271bbad01c4295e1a5b5c4aR265

My best guess would be that this is orthogonal to Jinja2 pre-compilation, and probably unnecessary for my case if we are pre-compiling...?

i.e. if JinjaX is just a Jinja extension and our templates include JinjaX components, then when we pre-compile the templates hopefully all the JinjaX stuff is resolved into raw Jinja ahead of time ...could you say if that seems correct?

[anentropic]

Hmm... looks like JinjaX keeps its own internal Jinja env though, so maybe to the outer template the JinjaX component is a black box, which is going to load and render its own templates at render time

[jpsca]

JinjaX currently works as a pre-processor, replacing all:

<Component attr="value">content</Component>

with function calls like:

{% call catalog.irender("Component", attr="value") %}content{% endcall %}

These calls are evaluated at render time. Each call loads the source of the component file, parses it to extract the names of CSS/JS files, required and/or optional attributes, pre-processes the template (replacing components with function calls, as before), and finally renders the new template.

The rendering still uses the Jinja cache, but the loading and parsing did not, as it was repeated multiple times if a component was used multiple times (like a <Button>). Hence, I added a custom cache in #30. The Jinja cache is still used when rendering the template.

The custom cache depends on the modified time of the component files. If you know the component file is not going to change while the application is running, such as in a production environment, you can create the catalog with auto_reload=False to deactivate the check.

I don't think the situation is bad for production... but it could be better by having a catalog.compile_templates() function that could insert the code of the components recursively, instead of just a call, so we could rely only in the Jinja cache.