Repository navigation
Update to async askama - #3606
GuillaumeGomez wants to merge 1 commit into
Conversation
github-actions
Bot
added
the
S-waiting-on-review
There was a problem hiding this comment.
While I like the async askama feature, I imagine it being used differently.
( also I'm happy to implement it).
I don't see much advantage in async, when we buffer the response anyways.
So the real value only comes for streaming responses.
initial idea would be somewhere in our render_response middleware, where we could return a streaming body instead of the full buffer.
|
|
||
| match item.write_into(&mut buf) { | ||
| Ok(_) => { | ||
| match item.async_render_with_values(NO_VALUES).await { |
There was a problem hiding this comment.
I think there is no real value from this being async?
If we want streaming responses while rendering we would probably build a small adapter using tokio::io::duplex so we can expose AsyncRead for axum.
| fn render_with_csp_nonce( | ||
| &mut self, | ||
| csp_nonce: String, | ||
| ) -> ::futures_util::future::BoxFuture<'_, askama::Result<String>> { |
There was a problem hiding this comment.
similar to what I asked on the library:
if the result is a String, what's the value in the async machinery?
|
☔ The latest upstream changes (possibly #3691) made this pull request unmergeable. Please resolve the merge conflicts. |
No description provided.