Add render_node() to render elements without parents.

[pelme]

This is an attempt at making it possible to render elements without a parent element.

• I do like fragments as plain lists and am not keen on introducing a Fragment element
• I also like that you typically can just print() or str() a htpy element and it gets rendered without having to import a render function. I think that should be the standard way of triggering a render. This function is therefore intentionally named render_orphans and not render to not confuse anyone into using it when a plain str() call would do.

What do you think about this @zulqasar @davepeck ?

References:

• Request for Blank or Empty Element #22
• Initial experiences using htpy #23 (reply in thread)

[davepeck]

I like this direction! (Still!)

I understand wanting to encourage use of str(an_element) when users have something that derives from BaseElement.

That said, I wonder if it's preferable to tie this method to the Node type, aka render_node(node: Node) -> _Markup. It feels like it sort of completes the htpy type story: all of Voter Bowl's methods return either Node or Element but not all of them return Iterable[BaseElement].

And yeah, I suppose that would mean there are two ways to render an Element (str(an_element) or render_node(an_element)) but I dunno, it doesn't feel that bad?

[pelme]

Hi @davepeck , thanks for your feedback. I have been contemplating about this and I think your suggestion makes sense.

I have updated the PR to name it render_node() and also added iter_node() which does the equivalent for iteration. As you pointed out, I think this completes the type story. The implementation was trivial since iter_node already did exist internally as _iter_children which arguably is a worse name. :)

The docs only mention render_node() in one place and there is a note to avoid it for regular elements. I hope that is enough to prevent people from using it instead of str().

[pelme]

render_node / iter_node was committed via 0c07a5a and released in 24.7.2!