fix #181: allow FilterExpressions in bird tags

[benbacardi]

This is a draft PR for #181. It's a bit of a reshuffle for parameters, in particular the Value class, where raw is now expected to be a FilterExpression (from django.template.base).

This means we can now call components as such, and the Django filters are correctly parsed:

{% bird button badge_count=users|length %}
  Users
{% endbird %}

A summary of the changes:

• the "bits" from a bird tag (and a bird:prop tag) are parsed into key/value pairs split on =, where the value is a FilterExpression instance
• this FilterExpression instance is passed directly to the Value class when parsing the Params from the node
• when rendering, the FilterExpression is rendered with the context to provide the final value, and this greatly simplifies the Value.render method
• a couple of additional lines of logic is required to handle when a value is an attribute rather than a prop, so that things like disabled=False disappear from the attrs rather than appearing as disabled="False"—i.e. to mimic current behaviour.

There is one side effect that I'm not sure whether it's a problem or not. Currently, a prop passed with an in-template value of False ends up with a value of None inside the component, but with the above changes it will come through as it was originally with False.

My biggest bugbear with it is having to test the VariableDoesNotExist before calling the filter's resolve function, because the function itself has no way to stop it swallowing the error and returning the default empty string. I'd rather not do this, but it would mean no longer supporting unquoted raw strings. Personally I think that'd be an improvement, though…

I'm only considering the PR a draft because it clearly needs your input, @joshuadavidthomas — and I'm also not sure how best to rewrite all the test_params.py tests that don't expect FilterExpression instances all over the place! I've rejiggle a couple of the other tests (but locally the asset tests are also failing for seemingly unrelated reasons, so I'm not sure what will happen when they're run under CI).

All thoughts appreciated! I realise this isn't a "one-line change" and therefore a trivial PR to review/approve/reject.

[joshuadavidthomas]

Yeah, this is going to take me a minute to work through 😅

Not sure of when I'll be able to set aside some time to dive in, but I promise I'll get to it ASAP. Thanks for taking the time to dive in and contribute! 🎉💚

[joshuadavidthomas]

Promise I haven't forgotten about this. I've been down the Rust/LSP rabbit hole working on https://github.com/joshuadavidthomas/django-language-server with any spare time I have. Sorry for just letting this sit here! Thanks for taking the time to work on it (and for the nice write up in your blog post)!

[benbacardi]

No worries, I know what it's like! 🧡