Support for NativeEnvironment instead of rendering to String

[noxasaxon]

Hi @mitsuhiko,
I was wondering if you think its possible for this library to support jinja2's NativeEnvironment feature, to parse code into a type other than string.

I feel like there's some magic involved in serde_json that might make this do-able, but I am also too new with rust to know whether looking into this would be a dead end 😆

[mitsuhiko]

What would you want to use this for? It can probably be done but supporting this type of feature is relatively complex.

[noxasaxon]

TLDR: Users can define jinja templates as input to a parameter for a Lambda Function, and our library will resolve that template to any type (not just String) before handing off the resolved parameter to their lambda's business logic.

Do you have an idea of where I should start poking around in minijinja to possibly make a PR, and what hangups to look out for?

---

Longer answer:
I'm experimenting with porting this library that enhances AWS Step Functions to Rust so we have the option to use Rust lambdas when necessary.

One of the key enhancements to Step Functions is that we provide a Global State, and jinja templating to reference things from global state when you send them to a specific lambda step (allowing things like list comprehensions without writing a specific lambda just for that use case). Because we are handing off resolved templates to a python function instead of HTML, it needs to resolve to any possible JSON type like int, array, etc.

[mitsuhiko]

Generally speaking I'm in favor of this but this goes beyond what I using myself. As you might be aware I'm generally using Jinja for expression expansion which is why Expression already exists. If you are willing to implement this behind a feature flag I'm very much in favor of having it but I am not using this use case myself so it's hard to provide myself.

[mitsuhiko]

I think the combination of #82 and the custom formatter support there is enough in the engine now that supports this use case.