Fix nested templates block #1029
Conversation
GuillaumeGomez
force-pushed
the
nested-templates-block
branch
2 times, most recently
from
ac82e67
to
ae96c56
Compare
|
And fixed clippy lints. |
GuillaumeGomez
force-pushed
the
nested-templates-block
branch
from
ae96c56
to
e034479
Compare
testing/tests/block_fragments.rs
Outdated
| @@ -11,7 +11,7 @@ struct FragmentSimple<'a> { | |||
| fn test_fragment_simple() { | |||
| let simple = FragmentSimple { name: "world" }; | |||
|
|
|||
| assert_eq!(simple.render().unwrap(), "\n\n<p>Hello world!</p>\n"); | |||
| assert_eq!(simple.render().unwrap(), "\n<p>Hello world!</p>"); | |||
There was a problem hiding this comment.
For all lines removal, I'm not sure whether it was bad before and this PR fixed it as a side effect or the opposite...
There was a problem hiding this comment.
Looking at this particular case, IMO the previous state was good and this PR breaks it.
{% block body %}
<p>Hello {{ name }}!</p>
{% endblock %}
Arguably this should render newlines before and after the p node?
| @@ -1813,6 +1817,7 @@ struct Buffer { | |||
| indent: u8, | |||
| // Whether the output buffer is currently at the start of a line | |||
| start: bool, | |||
| discard: bool, | |||
There was a problem hiding this comment.
So the previous PR added discard in WritableBuffer. Remind me why we have both and why we need to discard in both (instead of discarding in one of them only)?
There was a problem hiding this comment.
One is the actual string where we push content and the other is pending AST that wasn't pushed yet into the string.
So in this case, if we only want to render a specific named block, which is then followed by another one (which we're not interested into), both will get rendered. However, the block we want to render could also be in other blocks, so we still need to go through the whole tree of each present block, but only render the block that was specified.
testing/tests/block_fragments.rs
Outdated
| #[derive(Template)] | ||
| #[template(path = "blocks.txt", block = "section")] | ||
| struct Section<'a> { | ||
| values: Vec<&'a str>, |
There was a problem hiding this comment.
Nit: why couldn't this just be a slice?
testing/tests/block_fragments.rs
Outdated
|
|
||
| #[test] | ||
| fn test_specific_block() { | ||
| let values: Vec<&str> = vec!["a", "b", "c"]; |
There was a problem hiding this comment.
Nit: pretty sure this doesn't need the type annotation.
testing/tests/block_fragments.rs
Outdated
| @@ -11,7 +11,7 @@ struct FragmentSimple<'a> { | |||
| fn test_fragment_simple() { | |||
| let simple = FragmentSimple { name: "world" }; | |||
|
|
|||
| assert_eq!(simple.render().unwrap(), "\n\n<p>Hello world!</p>\n"); | |||
| assert_eq!(simple.render().unwrap(), "\n<p>Hello world!</p>"); | |||
There was a problem hiding this comment.
Looking at this particular case, IMO the previous state was good and this PR breaks it.
{% block body %}
<p>Hello {{ name }}!</p>
{% endblock %}
Arguably this should render newlines before and after the p node?
GuillaumeGomez
force-pushed
the
nested-templates-block
branch
from
e034479
to
eec5752
Compare
|
Mystery solved (for the missing trailing backline characters): I accidentaly removed |
|
I can confirm this resolved an issue I had where contents from the template leaked into the block-fragmented child template. I added another test case here: #1032 |
Fixes #1022.
Problem was that we were still rendering the content into the
WritableBuffer.