-
Notifications
You must be signed in to change notification settings - Fork 155
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make nested html!
invocations lazy
#381
Comments
In my project (using #373) I solved it like this: /// Helper for writing nested html_to!
/// Basically a lazy html! that can be rendered(-to) on demand
macro_rules! html_in {
($($tt:tt)*) => {
MaudFnWrapper(|buf: &mut String| maud::html_to!{ buf, $($tt)* })
};
}
/// A bit of closure magic to work around nested html_to!
struct MaudFnWrapper<F>(F);
impl<F> Render for MaudFnWrapper<F>
where F: Fn(&mut String) {
fn render_to(&self, buffer: &mut String) {
self.0(buffer)
}
} Howerer this is mainly a workaround, than proper solution. |
Cool! I'll take a look at that and maybe make a PoC of my idea. |
Implemented in Hypertext. How difficult would it be to use the same approach in Maud? |
It's probably fine. I think I was originally concerned about ergonomics around lifetimes, but the fact that other libraries don't care, as well as improvements on the Rust side, makes that concern unfounded. We'll still need to decide between |
Related to #373.
For patterns like this:
There is technically no need for the intermediate buffer from
body
, because the markup could render directly into the outer buffer.In my ideal API,
Markup
would just implementRender
(therender
method would have to return something other thanMarkup
, probably justPreEscaped<String>
) and take advantage of the existingrender_to
method.The text was updated successfully, but these errors were encountered: