Allow nesting sections in tags #59
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
It often happens that only one field from a subsecion is to be rendered.
For this, one currently has to write `{{#section}}{{field}}{{/section}}`,
which is quite verbose. This PR adds the posibility to write this as
`{{section field}}`, or to nest arbitrary many such subsecions, like
`{{section subsecion field}}`.
Furthermore, it allows opening arbitrarily many sections as
`{{#section subsecion subsubsection}}`, or closing them as
`{{/subsubsection subsecion section}}` (in the order they are closed).
Apart from readability, this should also improve rendering performance a bit,
since unnecessary closing blocks with no HTML data are not added
(`{{section field}}` doesn't require a closing block, the span of the section
is automatically calculated).
On my machine, surprisingly, the parsing benchmark also turns out a bit beter
than before, probably because trimming of whitespace and hashing of fields where
it is not necessary is eliminated.
This makes the hashes the same as in the `HashMap<&str, V, FnvBuildHasher>`, making it possible to get the field directly by its hash.
Reduces the number of dependencies and allows more flexibility in choosing the hasher.
maciejhirsz
reviewed
Jun 6, 2022
| @@ -212,7 +228,7 @@ mod test { | |||
| Block { | |||
| html: "", | |||
| name: "test", | |||
| hash: 0xf9e6e6ef197c2b25, | |||
| hash: 2271575940368597870, | |||
There was a problem hiding this comment.
So using the Hash trait instead of Hasher::write changes the hash for &str somehow?
There was a problem hiding this comment.
Yes, the Hash implementation appends 0xff after the string.
|
Published in 0.14. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It often happens that only one field from a subsecion is to be rendered. For this, one currently has to write
{{#section}}{{field}}{{/section}}, which is quite verbose. This PR adds the posibility to write this as{{section field}}, or to nest arbitrary many such subsecions, like{{section subsecion field}}.Furthermore, it allows opening arbitrarily many sections as
{{#section subsecion subsubsection}}, or closing them as{{/subsubsection subsecion section}}(in the order they are closed).Apart from readability, this should also improve rendering performance a bit, since unnecessary closing blocks with no HTML data are not added (
{{section field}}doesn't require a closing block, the span of the section is automatically calculated).On my machine, surprisingly, the parsing benchmark also turns out a bit beter than before, probably because trimming of whitespace and hashing of fields where it is not necessary is eliminated.