pauleveritt / fdom

Template engine based on tag strings and functional ideas.
0 stars 0 forks source link

Inner list comprehensions don't expand #14

Open pauleveritt opened 11 months ago

pauleveritt commented 11 months ago

This:

    message = "Hello"
    names = ["World", "Universe"]
    return html'<ul title="{message}">{[html('<li>{name}</li>')for name in names]}</ul>'

...results in:

<ul title="Hello"><li>{name}</li><li>{name}</li></ul>
jimbaker commented 11 months ago

Sorry, just seeing this issue.

So the problem is the use of the extra parentheses, which I attempting to highlight: [html('...') ...], it should be [html'...' ...]

Speciifcally the code should be

html'<ul title="{message}">{[html'<li>{name}</li>' for name in names]}</ul>'

which results in what we expect

'<ul title="Hello"><li>World</li><li>Universe</li></ul>'
jimbaker commented 11 months ago

And to be clear, what does the extra parens result in? It's just a regular string, which is why {name} is not evaluated:

html('<li>{name}</li>')

results in

'<li>{name}</li>'

This can cause confusion because a tag function takes *args: Chunk|Thunk (or alternatively, *args: str|tuple. So it happily takes '<li>{name}</li>', and then returns it, since that's valid HTML.

Note that it doesn't like an argument that is not HTML, like html('alice') reporting

AttributeError: 'str' object has no attribute 'attrs'

So that's invalid HTML, but it should fail deep in the compiler.

pauleveritt commented 11 months ago

I am SOOOOO sorry. This is a cut-and-paste mistake by me. My ViewDOM thing does html('<div/>') and I've seen it so much, I didn't spot it.

Want to close this? Should I make a ticket for the last point?

jimbaker commented 11 months ago

Let's keep it open for the following reasons:

  1. This is a gotcha that we should document, given that tag strings are novel.
  2. Fortunately editors should highlight this well, much like they do with f-string vs regular string. Linters can possibly help as well. We could mention that in the PEP as well.
  3. We should fix the last point; that could be a separate ticket as you mentioned.