Allow the use of template filters in arguments

[benbacardi]

Hey, I discovered this library coming from Tim Schilling's post about the new simple_block_tag landing in Django 5.2, and it looks to match exactly how I think about "components" fitting in with the Django Template Language, so thank you!

My one request would be to add support for template filters in the arguments to {% bird %}. Currently, this kind of thing is not possible:

{% bird:prop count=None %}
<button class="btn btn-primary">
  {% if count is not None %}<span class="badge badge-light">{{ count }}</span>{% endif %}
  {{ slot }}
</button>

{% bird "button" count=users|length %}
  Click me!
{% endbird %}

The component sees users|length as a single context variable and renders it as-is (due to the behaviour for missing variables). This is quite unexpected when you're used to how template filters work in other Django template tags, and it'd be great if it was supported.

[joshuadavidthomas]

Ah, good point! I was just about to work on a badge component for work and this was in my mind of things it should be able to do.

Should pretty a pretty easy fix, I'm pretty sure all you'd need to do is use FilterExpression here to parse out the filters:

https://github.com/joshuadavidthomas/django-bird/blob/main/src/django_bird/params.py#L107-L111

I'm open to a PR if you're up for it, otherwise I'll see if I can get to it soonish.

[benbacardi]

The template engine is not something I'm overly familiar with, but having a poke around, FilterExpression requires the parser, which is only currently available in the do_bird function. If we pass it through the chain

• do_bird passes it to the BirdNode instance
• … which passes it to the BoundComponent.render method
• … which passes it to the Params.render_props method
• … which passes it to the Value dataclass

We can eventually replace the case (str(raw_str), False): section of the render method with:

            case (str(raw_str), False):
                fe = FilterExpression(raw_str, self.parser)
                return fe.resolve(context)

Alternatively, we could avoid passing the parser around everywhere, and instead render a full template with the expression:

            case (str(raw_str), False):
                return template.Template(f"{{{{ {raw_str} }}}}").render(context)

Both these solutions work, but also remove the default behaviour of returning the raw value for variables that don't exist—it instead renders it using the template language's default "empty variable" behaviour. I'm not sure we'd be able to catch that easily?

I'm also not currently sure which of the above would be the best approach? We could perhaps limit this behaviour if we detect a | in the raw_str.

(Also, does bird support the Jinja2 template language? I'm assuming not…)

[joshuadavidthomas]

LOL, yeah that's what I get for the tossed off comment while on my phone of "oh yeah, it's easy just right here". Thanks for the quick dive!

This is one of those cases where the custom templatetag documentation is a bit thin and dealing with filters isn't actually officially documented. But if you look at some of the builtins, it looks like the right way to deal with this is via the Parser.compile_filter method -- here's a handful of examples from Django itself:

https://github.com/joshuadavidthomas/django/blob/d94b6733baa50eb53ee25761c789ccec7c56118c/django/template/defaulttags.py#L661-L661
https://github.com/joshuadavidthomas/django/blob/d94b6733baa50eb53ee25761c789ccec7c56118c/django/template/defaulttags.py#L773-L773
https://github.com/joshuadavidthomas/django/blob/d94b6733baa50eb53ee25761c789ccec7c56118c/django/template/defaulttags.py

So I wonder if the right place to actually do this is in the do_bird function, not the least because we have access to the Parser in the correct render context and don't have to pass it down to the library's BoundComponent/Param/Value abstractions.

django-bird/src/django_bird/templatetags/tags/bird.py

Lines 26 to 36 in 7407db7

	attrs: TagBits = []
	isolated_context = False
	for bit in bits:
	match bit:
	case "only":
	isolated_context = True
	case "/":
	continue
	case _:
	attrs.append(bit)

[benbacardi]

I'll try and dig into it a bit more later, but I think the best thing to do may be to reevaluate the approach to attrs, and make:

• BirdNode.attrs a dictionary of attribute name to FilterExpression objects (this can be compiled in the do_bird function)
• Value take a FilterExpression instance instead of a raw unevaluated string/bool/etc

That way, the Value resolve function can just resolve the FilterExpression, and the parser doesn't need to be passed around.

It means refactoring a little how Params are constructed from the Node, and I don't know all the implications of that, but it could be a relatively neat solution. We could end up not actually needing a Value class at all!

All of this would still break the "if the variable isn't defined, use the variable name" feature, which I'm not sure how to get around. It does go against what people are used to with Django, but it's also nice to not have to quote every literal… though that's potentially dangerous if you end up later creating a context variable with that same name and don't realise.

Sorry, bit of a brain dump there!