Pass variables to sub-templates more reliably even if indirectly#397
Conversation
|
Since we are doing a breaking release, I think this would be a good addition. It changes the signature of |
f9000ef to
9895d48
Compare
|
I removed the filter |
9895d48 to
69b6de4
Compare
69b6de4 to
6ff3b51
Compare
6ff3b51 to
ad7b930
Compare
| Ok(HtmlSafeOutput(Linebreaks(source))) | ||
| } | ||
|
|
||
| pub struct Linebreaks<S>(S); |
There was a problem hiding this comment.
Just to be sure: this commit is just about optimizing the rendering of the filters modified here, right?
There was a problem hiding this comment.
Sorry, I don't understand the question.
|
Wouldn't it make more sense to just provide the |
ad7b930 to
51f9d24
Compare
94db84d to
8abe84d
Compare
I want custom filters to remain as simple to use as possible for the average case. |
8abe84d to
f7fc39d
Compare
Is it though? Erf, It'd be nice if we could have a survey for this or something... I have a few thousands followers on socials so we can actually do it now that I think about it. What do you think? If you agree, then we need to have a short explanation on the two possibilities:
|
|
|
|
Thinking again about it, no, simply passing the runtime values as a filter argument would solve nothing: The runtime values need to be passed on to the filter source, if it can accept this argument, and we still want to be compatible with any fmt::Display input. |
|
The idea I had was to force all filters to have a |
|
I meant, even if we provide the argument to custom filters, the rest of the changes are still needed. I'm happy to review a different solution, though, I could not come up with another solution. :) The only problem I see with always providing the value is that we lose one register if the filter is not |
| ### Runtime values | ||
| [#runtime-values]: #runtime-values | ||
|
|
||
| It is possible to access [runtime values](./runtime.html) in custom filters: |
There was a problem hiding this comment.
So if Values is always provided, I suppose we need to update this part, right?
Also, might be nice to add docs about FastWritable. Gonna open an issue for it.
There was a problem hiding this comment.
But an example would still be nice for using Values in filters!
There was a problem hiding this comment.
There was a problem hiding this comment.
This example is "advanced" (not sure how to word it better). Since now filters all receive the Values argument, they just need to make use of it, no need to return a type implementing FastWritable. "Simpler is better" yada yada, you know the drill. 🤣
However, it'd be nice to also add a chapter in the book about FastWritable (hence why I opened #402).
There was a problem hiding this comment.
The example already is simplified, without special return types, etc. Have a look, maybe you didn't see the changes in my last force-push. :)
There was a problem hiding this comment.
Oh indeed. Sorry about that. ^^'
No description provided.