altair-bueno / axum-template Goto Github PK

I'm sure you're already aware but either way may be useful to have a tracking issue for this.

Changelog including breaking changes available here.

Thank you for this crate!

Would it be possible to enable RenderHtml to accept the Tera Context instead of a struct? Some handlers might need to return RenderHtml with different templates (and thus different Models) and as far an I can see that won't work.

infinity recursion call on

impl IntoResponse for TeraError fn into_response(self) ;

My use case is to listen on changes in the template directory and reload the templates (with Tera::full_reload()).

I'm not sure how to provide the required &mut Tera though.

Hello,

I'm not super experience in rust nor with axum, so maybe there's an easy solution I miss, but I was wondering how I could access the Tera object while using axum-template. My goal would be to reload template using tera.full_reload() in development and only load them once in production.

• Changelog (migration notes) https://github.com/tokio-rs/axum/blob/main/axum/CHANGELOG.md
• Blog post https://tokio.rs/blog/2023-11-27-announcing-axum-0-7-0

Hey,
I like what you did but would like to add suggestion (I actually wanted to create a similar crate in the first place).

It should be possible to extract the MatchedPath and Engine in the FromRequestParts Trait by introducing a Trait to extract the engine from the state (ideally the trait can be applied like FromRef via a macro).

This allows to render the tenplate via a simpler simpler function call and also it requires only 1 parameter instead of 2 for each handler.

I haven't tested if it works but it shoud simplify the api drastically for users.

I've ran into this situation:

async fn handler(
    engine: impl TemplateEngine,
) -> impl IntoResponse {
    let key = "Template key";
    let data = Person{ /* */ };
    RenderHtml(key, engine, data);
}

This renders nothing on the output and also produces no warnings!

Since RenderHtml is not marked #[must_use] the compiler happily ignored it and used the default return value of () as my IntoResponse implementation.

Having #[must_use] here would at least tell me something is up, and fix the error. (Since ; is also fairly small and easy to miss)