Loader re-loading every time

[joelmichael]

I am using path_loader in the conventional way. I thought it would keep a template stored after the first call to get_template. However, when I refresh my site I find it's reloading the template; I can tell because changes to the template I make show up without a server restart. I don't think this is the intended behavior, as clear_templates is provided if I want frequent reloading (for local development). I am using Axum and initializing the Environment var and passing it around to handlers through a state struct. Any help would be appreciated. This happens on versions 1.0.8 and 1.0.9. Thanks

[joelmichael]

It seems the solution is that I need to call get_template on each template when I initialize my Environment. I tried that before, but was confused because the code I found for extracting the filename from dir entries using format!("{:?}", entry.file_name()) was adding quote characters around the string, e.g. "home.jinja" instead of home.jinja.

This works:

async fn init_jinja_env() -> minijinja::Environment<'static> {
    let mut env = minijinja::Environment::new();
    env.set_loader(minijinja::path_loader("templates"));
    if std::env::var("DEV").is_err() {
        for entry_res in std::fs::read_dir("templates").unwrap() {
            let entry = entry_res.unwrap();
            let file_name = entry.file_name().into_string().unwrap();
            _ = env.get_template(&file_name);
        }
    }
    env
}

Unrelated, but thank you for the great library!

[mitsuhiko]

I'm confused how this is possible. The loader will only load a template once. You can easily validate this yourself:

use std::collections::BTreeMap;
use std::sync::Mutex;

#[test]
fn test_load_once() {
    let mut env = Environment::new();
    let loaded = Mutex::<BTreeMap<String, usize>>::default();
    env.set_loader(move |name| {
        let mut loaded = loaded.lock().unwrap();
        let x = loaded.entry(name.to_string()).or_default();
        *x += 1;
        Ok(Some(format!("loaded {} times", *x)))
    });

    let x = env.get_template("index.html").unwrap();
    assert_eq!(x.render(()).unwrap(), "loaded 1 times");
    let x = env.get_template("index.html").unwrap();
    assert_eq!(x.render(()).unwrap(), "loaded 1 times");
}

I wonder if what you run into is that the loader loads lazily which means that you might not have seen it before yet. That lazy loading behavior is quite intentional, but obviously iterating over known templates and loading them once will prime it.

[joelmichael]

I think the request handler being used by Axum is adding the template, but then it's returning to its initialized form for the next request. Here's the most common code I use to render a template:

pub fn render(jinja: Environment<'_>, name: &str, ctx: Value) -> String {
    let tmpl = jinja.get_template(name).expect("gets template");
    tmpl.render(ctx).expect("renders template")
}

This is called by an Axum handler like so:

pub async fn home(State(state): State<AppState>) -> Html<String> {
    Html(render(state.jinja, "home.jinja", context!()))
}

The state.jinja var here refers to an Environment that is initialized in main.rs and then passed to the Axum router via with_state.

It seems the get_template call here probably does modify the Environment, but then on the next request, Axum returns to using the originally initialized Environment passed into the Axum router. That is my best guess.

[mitsuhiko]

That would imply that you're cloning the Environment over and over. I would strongly recommend to store the Environment as Arc<Environment<'static>>. That way the clone becomes almost free (refcount increment) instead of cloning the environment over and over again. That would also prevent the oddity you are running into with templates reloading unexpectedly.

[joelmichael]

Ah, I'm not very familiar with Arc yet. I gave it a shot, and found I also had to add a Mutex if I want to use clear_templates in development mode. However, it all seems to work now with this code:

async fn init_jinja_env() -> Arc<Mutex<Environment<'static>>> {
    let mut env = Environment::new();
    env.set_loader(minijinja::path_loader("templates"));
    Arc::new(Mutex::new(env))
}

and

pub fn render(
    mutex: &Arc<Mutex<Environment<'_>>>,
    name: &str,
    ctx: Value
) -> String {
    let mut env = mutex.lock().unwrap();
    if std::env::var("DEV").is_ok() {
        env.clear_templates();
    }
    let tmpl = env.get_template(name).expect("gets template");
    tmpl.render(ctx).expect("renders template")
}

I'm not really sure of the performance implications of locking a Mutex in an Arc vs the old way I was doing, which was apparently cloning the environment every time rather than maintaining a "state". This way does seem more like the intended purpose of a state variable. I appreciate your help!

[mitsuhiko]

Another way to skin the cat would be to stick with just the Arc but to clone the environment in dev mode. That way the modifications done by loading the template are not persisted as before, and you avoid the need of the otherwise pointless mutex.

[joelmichael]

I'm trying that now, but I'm not sure how to get the Environment out so that I can clone it. It seems using Arc<Mutex<>> is the recommended way for having mutable state in Axum. In trying to extract the Environment from the Arc, either by using the dereference operator * or calling Arc::into_inner, I'm not having any luck. Cloning the Arc itself would just produce another pointer to the same Environment. So far as I can figure out, the Mutex solution with clear_templates in dev mode is still the best one I have so far.