Question re how JinjaX interacts with Jinja2 pre-compiled templates (ModuleLoader) about jinjax HOT 2 CLOSED

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

from jinjax.

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.

from jinjax.