Add html_element to ensure returning an Element?

[pauleveritt]

My tests wind up doing assert isinstance(result, Element) after every usage because html() returns a Node and the type checker immediately gets mad at result.children and similar accesses.

[pauleveritt]

Revisiting this and curious if @ianjosephwilson has any thoughts. We can lose this thread if the status quo is as-expected. Workarounds are available (per-project helpers.)

[ianjosephwilson]

This comes up when we were working on the parser changes. I think we need to kind of "re-walk" the implementation and then think about usage and performance to decide what to do. From a software stability perspective I was thinking everything should return a fragment or "container" equivalent (TElement, TComponent) but I don't know if that would create weird terrible performance situations where we just unpack a fragment's children over and over and over again or even worse.. take a node and stuff it in a fragment and then unpack that same fragment 2 calls later (over and over again).

• Do we expect to work with runs of exclusively Text or TText nodes very often? (I think that would be very rare)
• What is a t-string? Should we consider it always to be a fragment of some sort? (I think it is implicitly a fragment)
  • What should we do with this madness, trailing/leading whitespace: t"<div>my content</div> " (leave as-is, in a fragment)
    • If we take it out then we need to let you say when not to, or keep in that anonymous fragment syntax (<></>)
  • trailing/leading text seems more intentional: t"His name was Bingo" (leave as-is, in a fragment)
  • I would like to support minimizing html and not force using extra tags just to "make things work/easy" with tdom's implementation, within reason, i think that just leads to confusion later, ie. why is all this text wrapped in spans? (an example might be wrapping whitespace or text in spans to change behavior of the parsing, I don't think we want that)
• Will we ever consider void elements as strictly not having children? TDom seems pretty soft on this rule and we just make an element with no children. (I think how it works now is what we want and works well )

In general I'm kind of on the side of t-strings should be "blocks" of html and not just a single tag. That kind of seems like the best way to leverage the expressiveness of them otherwise it is just another tag builder, maybe even a lower quality one because of the all the indirection.

parse_html() to return TFragment|TElement|TComponent

This really comes up here (where I fiddled a bit with the prior logic which used to be a Text("") if parse("")

tdom/tdom/parser.py

Line 341 in e8f219a

def get_node(

I think this is where we probably need more adjustment:

tdom/tdom/parser.py

Line 355 in e8f219a

elif len(self.tstate.root.children) == 1:

I think something like this would always give us a Fragment/Element/Component:

• default wrap a t-string in a fragment
• if the fragment is just a single node and that node is a container then extract it and throw the fragment away (fragment/element/component)
• otherwise just keep the wrapped fragment (its text-only nodes, a comment, a doctype, its multiple nodes but no single root, we didn't parse anything at all)

Change html() to return Fragment|Element

A similar situation could happen in https://github.com/t-strings/tdom/blob/main/tdom/processor.py#L415

Where we wrap the result in a fragment if it isn't a "container".

[ianjosephwilson]

@pauleveritt Do you just need a type that has .children or does it specifically have to be Element?

[pauleveritt]

@ianjosephwilson Doesn't specifically have to be Element. Looks like my tests have an equal spread of type guards for .attrs and .children accessors.