Open mattfbacon opened 1 year ago
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.
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.