Replies: 2 comments 2 replies
-
Thanks for picking up the discussion and implementing this such that it covers all possible invokation methods and being compatible with Renderable! I want htpy to be kind of neutral about how to write components/structure your code and encourage make use of regular Python constructs and treat htpy components just like any other code you write. That said, I also do not want everyone to reinvent the patterns by themselves. But I am not exactly sure where to draw the line on what is too opinionated. It is clear that there are interest in So I am not against adding it to htpy and would not be against adding more helpers in the future if there is some kind of consensus about it. Feel free to open a PR if you like and we can continue the discussions there. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Background and requirements
As several others before us, we also like building custom htpy components that work just like the "native" htpy elements. That is, to make custom components that are not just regular functions:
But instead make components that can accept children elements through
__getitem__()
:We wanted all of these to work anywhere a component can be used:
And finally, with the
Renderable
protocol (#92) around the corner, it should also be supported:Implementation
Here is our implementation with tests. It should work both with the current htpy release and the upcoming one with
Renderable
support. Once #92 is released, the type bounds forR
should be changed fromhtpy.Node
tohtpy.Renderable.
htpy_with_children.py
test_htpy_with_children.py
Future
If there is interest in having this as part of htpy, that would be awesome.
If not, and there is interest in having something like this around without having to copy or reimplement it in every project, I'm open to maintaining this as a separate Python package.
Is this a pattern many of us use? Is this implementation everything we want, or is there anything missing? Let me know what you think.
Beta Was this translation helpful? Give feedback.
All reactions