Replacing syntax of attributes: using :name="expression" instead of name={expression}

[jpsca]

Current Status

The current syntax uses single curly braces to indicate that a component attribute/property/argument is actually an expression, instead of a literal string:

<!-- foo is a literal string, modal, message, and size are expressions -->
<Greeting modal={False} message={message} size={2+2} foo="bar" />

The single curly braces are used for parsing the values. This would be translated internally to:

{{ catalog.irender("Greeting", modal=False, message=message, size=2+2, foo="bar") }}

Proposal

The single curly brace can be confusing in a template full of Jinja's double curly braces ({{).

So, what I'm thinking is to change the syntax for passing values to components by using Vue.js syntax: quoting everything but prefixing the name of the expression attributes with a colon (:). The example above would be written like this instead:

<!-- foo is a literal string, modal, message, and size are expressions -->
<Greeting :modal="False" :message="message" :size="2+2" foo="bar" />

[JakobGM]

I don't think I have a strong opinion here, or at least not on aesthetic grounds. My main interest in this topic is if this new syntax would allow the application of prettier or similar tools to indent/auto-format our components. @davidodentwald has done some work on this with prettier-plugin-jinja-template, but it has proven a bit unreliable unfortunately, and I think that is because of the brace-based syntax.

Being able to apply prettier would be a huge win from this feature, if that is the case!

[jpsca]

I went ahead and did it!

https://github.com/jpsca/jinjax/releases/tag/0.4

[anentropic]

I like it!

the docs don't seem to explain this syntax anywhere though (?)

e.g. https://jinjax.scaletti.dev/guide/components/#/ shows:

<Form action="/new"> ... </Form>
<Form action="/new" method="PATCH"> ... </Form>
<Form :multipart="False" action="/new"> ... </Form>

but it's not immediately clear why multipart has a colon in front and the others don't

(I understand why after reading this discussion)

[edager]

Hi @jpsca
I use JinjaX a lot as it really does increase clarity. Unfortunately, I didn't notice this post earlier so I could have voted against the syntax change.

Firstly, introducing a breaking change solely for aesthetic reasons that doesn't simplify the syntax is problematic.
Secondly, I think colon prefixing an attribute name to show that it's value is an expression doesn't really have a counterpart in HTML to my knowledge, so unless people have used Vue.js it's unclear to them. It also looks quite awkward for dynamically typed languages such as Python which JinjaX would be used with it.

That such large changes can be introduced without an intermediate version that raised deprecation warnings, makes me question a bit whether to fork my own branch of jinjaX to ensure I can stay updated while not suddenly have my codebase break down.

Again, I use JinjaX a lot and I like it, it's just my opinion as a user. Please reconsider using this syntax.

[jpsca]

@edager

Sorry, I really dislike the single curly brace syntax and I regret waiting this long to change it.

However, maybe this change will make you feel better. Since version 0.42, double curly braces syntax is supported, so both of these syntax are now valid:

{# Jinja-like #}
<Example
    columns={{ 2 }}
    tabbed={{ False }}
    panels={{ {'one': 'lorem', 'two': 'ipsum'} }}
    class={{ 'bg-' + color }}
/>

{# vue-like #}
<Example
    :columns="2"
    :tabbed="False"
    :panels="{'one': 'lorem', 'two': 'ipsum'}"
    :class="'bg-' + color"
/>

[pietz]

I don't know why I'm so obsessed with this topic, but wouldn't this be super easy and plain?

<Element num=2 text="Hello" var=foo />

Basically Python syntax without the commas.

The only workaround would be needed for expressions consisting of multiple parts like in the "Example :class" above. This probably happens rarely and we could use parentheses class=("bg-" + color)

[jpsca]

@pietz Yes, it would be easier to type... however I would probably need to write a real parser to do it... and still support the var={{ foo }} syntax... so YES, but probably not soon.

Here's a quick rundown of the proposal:

• If it begins with ", parse until the next non-escaped " and return as text.
• If it begins with {{, parse until }} and return as an expression.
• If it begins with (, parse until the matching ) and return as an expression.
• If it begins with anything else, parse until the first space and return as an expression.
• If there is no =, return True.