Closed pelme closed 4 months ago
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?
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().
render_node
/ iter_node
was committed via 0c07a5a99c40f88ba4266e9b9de7b179adc4f225 and released in 24.7.2
!
This is an attempt at making it possible to render elements without a parent element.
print()
orstr()
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 namedrender_orphans
and notrender
to not confuse anyone into using it when a plainstr()
call would do.What do you think about this @zulqasar @davepeck ?
References:
22