-
Notifications
You must be signed in to change notification settings - Fork 36
Add conditional expressions #536
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
base: main
Are you sure you want to change the base?
Conversation
@GuillaumeGomez, so what do you think of this feature? Documentation and UI tests are missing, but the functionality is all there. If you give me a ":+1:" on the feature, I'd add the missing parts. |
I'm not convinced. The syntax is really different compared to the rest. Adding conditional expressions inside the "expression tag" seems a bit too much imo. It's just the first step. I'm working on the second step currently and hopefully it'll crazily improve nightly outputs, even if you write stuff like: #[derive(Template)]
// And other attributes
#[template(src = "{{ x.y }}")]
struct X {
x: u32,
} It'll be able to show directly that the |
Actually, I use is pattern all the time in jinja templates. Simple things like (At least for templating, I like python's "infix |
Hum... Well I don't really a strong argument against it either. Is there syntax conflict possibility? That's my main worry here. |
Only with That's why I introduced |
); | ||
|
||
compare( | ||
r"{{ a if b else c if d else e }}", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is absolutely horrifying for my brain to parse. 🤣
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about this formatting? :)
{{
a if b else
c if d else
e
}}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That doesn't help much, I'm too used to blocks. But it's fine, don't worry. One question though, does this work:
{{ a if b else (c if d else e) }}
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that does work.
Thinking some more, does it mean we can have stuff like: {{ a(x if y else z) }}
{% if (a if x else b) %} ? |
Yes! Both examples would work. |
I'm very afraid of opening this door. 🤣 |
Anyway, I don't any valid argument against this feature, so if you have a use for it and want to add it, then let's go. Please ping me once PR is ready for review with tests and docs. :) |
ec6d66b
to
f278964
Compare
Jinja, being based on Python, allows using conditional expressions: ```jinja {{ "then" if condition else "otherwise" }} ``` will print `"then"` if `condition` is truthy, otherwise `"otherwise"`. This PR adds the same syntax, with a few restrictions, to Askama: * The condition must evaluate to a `bool` (or a reference to it), same as in `{% if .. %}`. * The else-case can be absent in Jinja, then behaves like `else None`. For Jinja that makes sense. It renders `{{ None }}` like an empty string. Askama does not do that: `Option<T>` can not be rendered for any `T`; we don't unwrap automatically. So, without automatic unwrapping, I don't see a case when you would want to omit the else-case.
Jinja, being based on Python, allows using conditional expressions:
will print
"then"
ifcondition
is truthy, otherwise"otherwise"
.This PR adds the same syntax, with a few restrictions, to Askama:
bool
(or a reference to it), same as in{% if .. %}
.else None
. For Jinja that makes sense. It renders{{ None }}
like an empty string. Askama does not do that:Option<T>
can not be rendered for anyT
; we don't unwrap automatically. So, without automatic unwrapping, I don't see a case when you would want to omit the else-case.Todo: