Open vallentin opened 4 months ago
I like display_some
and display_some_or
, and those are pretty good names. @GuillaumeGomez @Kijewski any thoughts?
I'm not as convinced about the Result
filters for now.
Wouldn't it be better to support if let Some(value) = val
instead?
Wouldn't it be better to support if let Some(value) = val instead?
I think it is.
That's fair, too. How much of the current match
parsing could we reuse for that?
Didn't check yet but I suppose it shouldn't be too difficult to add.
{% if let Some(x) = y %}
is already implemented: https://github.com/djc/askama/pull/503. Or do I misunderstand what you mean?
TIL. Well then, is there any point in having a filter in this case?
@vallentin any thoughts? Were you aware if let
is supported now?
I even reviewed #503, but somehow completely forgot about it.
Personally, I would still say that this:
{{ id|display_some }}
{{ id|display_some_or("default") }}
Is less verbose than this:
{% if let Some(id) = id -%}
{{ id }}
{%- endif %}
{% if let Some(id) = id -%}
{{ id }}
{%- else -%}
default
{%- endif %}
Personally, I prefer removing as much logic from templates as possible.
Additionally, using if let
requires you to think about the whitespace control.
However, given that if let
is supported, then I would understand, if these don't cut it as a built-in filters, even though I would personally advocate for having them.
I'd argue that having more filters to have a shortcut on what's already possible is not a great added value. In addition, in here the difference is really small, so I personally don't think it's worth it.
I do understand, as I completely acknowledge my bias in this case, since I've grown accustomed to using them and having short and concise logic-less templates
Actually I kinda like display_some
and display_some_or
and I'm sensitive to the conciseness argument for something that's arguably pretty common.
I am in favor of the new filters, too! {{ data|display_some_or("?") }}
is much more readable than
{% if let Some(data) = data -%}
{{ data }}
{%- else -%}
?
{%- endif %}
Alright, I'll make a PR for it. I have all the code ready anyways, just need to update the book
The question of how to render a
Option<T>
comes up every now and then. So I think it's time to provide a simpler built-in solution.Today, I answered a question on Stack Overflow, including 5 solutions. I think we should include a built-in
display_some
filter.In #717 @djc suggested naming it
or_empty
._Personally, I think the name
display_some
is more clear, sinceval|or_empty
, might be confusing for e.g.val: Option<i32>
or any otherOption<T>
thanOption<String>
._I've had a handful of
display_*
filters locally since forever. So I propose that we include (some of) the following:Personally, I think
display_some_or
'sotherwise
should remain asU
, instead of&Option<U>
. Since the main need I've had over the years, have been in the form of e.g.:If I needed
a.or(b).or(c).unwrap_or("default")
, then I would instead do:Even though this logic should probably be handled outside of the template in the first place.
Additionally, my local implementation doesn't actually return
String
, they returnDisplay*
, e.g.DisplaySome
, whereDisplaySome
implfmt::Display
to avoid theString
allocation.So actually, what I want to add is:
Additionally, I also have
display_*
functions forResult
, which might also be useful to include:_The
display_ok_err()
is mainly useful for debugging._The
display_ok
anddisplay_err
filters, are mainly useful when you want to renderOk
vsErr
in separate places, e.g.Compared to:
I have the implementation locally, so I just need some opinions on which filters to include as built-in, and any other comments, before making a PR for them.