Trying to understand newtype behavior

[dfego]

Hi there! I've developed a relatively simple example and I don't understand what is causing the behavior I'm seeing and how to get it to do what I'd like.

In the example below, I've got a private type (Private) which I wrap in a newtype (Public). On that newtype, I have a method, public_name(), which is intended to abstract away the inner private_name. When I run the above code, it seems like {{ data }}, which is a reference to a Public struct, automatically is just Private inside the template context.

use minijinja::{Environment, context};
use serde::Serialize;

#[derive(Serialize)]
struct Private {
    private_name: String,
}

#[derive(Serialize)]
struct Public<'a>(&'a Private);

impl<'a> Public<'a> {
    fn new(private: &'a Private) -> Self {
        Self(private)
    }

    fn public_name(&self) -> &str {
        &self.0.private_name
    }
}

fn main() {
    let mut environment = Environment::new();
    environment.add_template("base", "{{ data }}").unwrap();

    let private = Private {
        private_name: "private string".into(),
    };
    let public = Public::new(&private);

    let template = environment.get_template("base").unwrap();
    let rendered = template
        .render(context! {
            data => &public,
        })
        .unwrap();

    println!("{rendered}");
}

Running the above prints:

{"private_name": "private string"}

I would expect it to... not? Shouldn't it be a tuple? Separately, is there any way to access methods, like public_name()?

The above is all contrived, but what I'm really trying to do is pass some structs from another crate with my own wrapping that limits and transforms the fields a bit. Rather than initialize a bunch of fields based on the external struct, I figured it made more sense to wrap the functionality in methods, but that doesn't seem to be possible any way I've tried.

[mitsuhiko]

With MiniJinja you have two options. One option is to go via serde in which case the object is effectively turned eagerly into a Value. The second option is to implement Object. In that case the value has to be 'static but it can hold on internally to stuff. I generally recommend going via Object if you want to custom implement stuff because it's more efficient and you do not need to implement a custom serializer to make it behave like you want.

For instance this is what you might want:

use std::sync::Arc;

use minijinja::value::{Enumerator, Object};
use minijinja::{Environment, Value, context};

#[derive(Debug)]
struct Private {
    private_name: String,
}

#[derive(Debug)]
struct Public(Arc<Private>);

impl Public {
    fn new(private: Arc<Private>) -> Self {
        Self(private)
    }

    fn public_name(&self) -> &str {
        &self.0.private_name
    }
}

impl Object for Public {
    fn get_value(self: &Arc<Self>, key: &Value) -> Option<Value> {
        match key.as_str()? {
            "public_name" => Some(Value::from(self.public_name())),
            _ => None,
        }
    }

    fn enumerate(self: &Arc<Self>) -> Enumerator {
        Enumerator::Str(&["public_name"])
    }
}

fn main() {
    let mut environment = Environment::new();
    environment.add_template("base", "{{ data }}").unwrap();

    let private = Arc::new(Private {
        private_name: "private string".into(),
    });
    let public = Public::new(private);

    let template = environment.get_template("base").unwrap();
    let rendered = template
        .render(context! {
            data => Value::from_object(public),
        })
        .unwrap();

    println!("{rendered}");
}

Note that in this case you need to use Value::from_object in the context and you need to hold on to your private data in an Arc as you cannot use a lifetime there.

The docs for Object have more examples: https://docs.rs/minijinja/latest/minijinja/value/trait.Object.html

[dfego]

Thank you for the response! When you say my first option is to use serde, am I not already doing that? I'm pretty sure I had to derive Serialize to get it to compile in my example. If not via serde, how is my struct currently getting serialized?

But now that I'm thinking about it further, are you saying that the route is implementing my own serialization for my struct? When I looked briefly at the serde docs, I expect that my struct would NOT be "transparent" since it's an explicit option for containers.

Lastly, does minijinja support calling methods on the objects in the context in the template? E.g. calling display_name()? I got an error when I tried.

[mitsuhiko]

When you say my first option is to use serde, am I not already doing that? I'm pretty sure I had to derive Serialize to get it to compile in my example. If not via serde, how is my struct currently getting serialized?

You are doing that, but you then get the behavior that serde implements for newtypes. Which for newtypes is just serializing what's inside. You either need to implement a custom serializer on Public or you need to use Object. To detect if you are serializing for minijinja uses within a serde serializer you can use this method to customize it: https://docs.rs/minijinja/latest/minijinja/value/fn.serializing_for_value.html

But now that I'm thinking about it further, are you saying that the route is implementing my own serialization for my struct?

Yes, that would be an option.

Lastly, does minijinja support calling methods on the objects in the context in the template? E.g. calling display_name()? I got an error when I tried.

It does when you use objects. The example I used did not implement display_name as method but as attribute, but you could also use this example to expose it as a method:

use std::sync::Arc;

use minijinja::value::{Object, from_args};
use minijinja::{Environment, Error, ErrorKind, State, Value, context};

#[derive(Debug)]
struct Private {
    private_name: String,
}

#[derive(Debug)]
struct Public(Arc<Private>);

impl Public {
    fn new(private: Arc<Private>) -> Self {
        Self(private)
    }

    fn public_name(&self) -> &str {
        &self.0.private_name
    }
}

impl Object for Public {
    fn call_method(
        self: &Arc<Self>,
        _state: &State<'_, '_>,
        method: &str,
        args: &[Value],
    ) -> Result<Value, minijinja::Error> {
        match method {
            "public_name" => {
                // this takes no arguments
                from_args::<()>(args)?;
                Ok(Value::from(self.public_name()))
            }
            _ => Err(Error::from(ErrorKind::UnknownMethod)),
        }
    }
}

fn main() {
    let mut environment = Environment::new();
    environment
        .add_template("base", "{{ data.public_name() }}")
        .unwrap();

    let private = Arc::new(Private {
        private_name: "private string".into(),
    });
    let public = Public::new(private);

    let template = environment.get_template("base").unwrap();
    let rendered = template
        .render(context! {
            data => Value::from_object(public),
        })
        .unwrap();

    println!("{rendered}");
}

You will find a lot of examples all over the documentation about how Object works and also in the examples folder: https://github.com/mitsuhiko/minijinja/blob/main/examples/dynamic-objects/src/main.rs

[dfego]

Thank you. I see (and can understand why) the intended usage leans towards implementation of these traits, since they're purpose-built for the task at hand. I'm a little curious why 'static lifetime would be required by the code in the above case. Shouldn't the data only need to live as long as the template environment?

[mitsuhiko]

Values are reference counted runtime objects and the lifetime cannot be carried through the engine. That is also true for the Serialize case. The object undergoes a full transformation via the Serialize trait into a Value which is also 'static.