Omit inner html() calls

[pauleveritt]

(I discussed this with @WebReflection in Discord.)

As an example, this fails:

inner = t'<{Heading} title="My Title" />'
result = html(t"<div>Hello {inner}</div>")

The inner Template isn't evaluated:

'<div>Hello Template(strings=(&#x27;&lt;&#x27;, &#x27; title=&quot;My Title&quot; /&gt;&#x27;), interpolations=(Interpolation(&lt;function Heading at 0x103e96c90&gt;, &#x27;Heading&#x27;, None, &#x27;&#x27;),))</div>

When using deeply-nested component calls, the extra html() can be cumbersome. It would be nice to build up a tree that includes unrendered Template then, later in the chain, render to a string.

[pauleveritt]

This originated with @davepeck

[WebReflection]

not much to discuss to me ... I'll try to land a fix as the expectation seems reasonable. The implementation will likely just implicitly pass through html(t_reference) when a t_reference is an interpolation, and the html could be svg in case the container is not an html one.

I think this should work without issues.

[WebReflection]

done: #13

[pauleveritt]

@WebReflection Omitting the inner html() will help a lot. I'm curious if there is a way to leave out the else "".

Just brainstorming. For example:

show_heading = False
heading = t"Hello {name}"
result = t"{show_heading and heading}"
print(list(result))
# [Interpolation(False, 'show_heading and heading', None, '')]

It's not that clean, but we could support a convention that detects this situation.

[WebReflection]

that is a discussion a part ... what is False ??? if we say False as content should never exist I can put empty nodes instead of False as text node in there but it's really a different discussion ... let's focus on the fact we're not clear when interpolations should be resolved, which is the current discussion, if I understood it correctly ... let's leave False outside this conversation.

Right now, html or svg change the parsing goal because in svg HTML rules don't always apply (and vice-versa) ... we could resolve at rendering time but interpolations in interpolations cannot be fully understood if not inside/out + templates are immutable so I can't resolve these when their interpolation contains templates ... I can do it one level, as the MR suggests, I can't do it recursively and I feel like doing it one level breaks devs expectations otherwise fully preserved with the current "boring" approach with html as resolver around ... or maybe I can do nothing and resolve everything only on render?

one thing that should be clear is that this should work:

html(t'''
  <{SVGComponent}>
    {svg(t'<rect x={1} y={2} />')}
  </>
''')

so somehow stuff needs to be resolved at some point and not just on render because svg in html is a perfectly valid use case

[WebReflection]

P.S. without html or svg resolvers basically the cache is useless for repeated same nodes (a list of <LI /> as example) ... but maybe doing nothing and resolve the world all at once on render can change that ... although that is a huge rewrite that won't happen before PyCon US, I am afraid

[WebReflection]

idea ... I could make html and svg intermediate carriers of the template and its intent (that is html or svg) and resolve all the things on render instead of having these already resolved ... this might work but it's still a bit unclear what is the final desired goal/outcome so any example/detail would help me moving forward with a better approach than current MR which is not really solving the underlying requirement to me

[pauleveritt]

Sigh...I put my comment about False in the wrong browser tab. It should have been in the discussion. I'm sorry, I've been writing my lightning talk this morning while having this conversation.

[pauleveritt]

Closing. We don't even know if the world of Python will find a way to language-inject HTML into a t-string if not surrounded by html(). Also: you've listed quite a number of related points that need more "you" involved than just me.

Let's stay with what we have and focus on examples and uses. Then, when we have more people, consider deeper changes.