undefined | Better HN

0 pointsvolfpeter1y ago0 comments

You're right, fetching all the data (that you may or may not need during rendering) in advance is of course doable and quite common. That's what you do for example with tools like Jinja. That may or may not work well for your use-case.

htmy does not force you to put data fetching or anything else into components (you can still have dumb components). It also doesn't force you to write async components. The most important thing it does is it gives you the option to build your application entirely in Python (no ugly custom templating language syntax with lack of static analysis or proper IDE support) and enables the use of modern async tools.

And admittedly, the lib was built with FastAPI and HTMX in mind, which kind of necessitates async support...

0 comments

anentropic1y ago

My comment was just thinking out loud really...

It seems like if you're not doing data fetching in the component then there's no need for it to be async.

And then I was wondering if maybe data fetching in components was a good pattern. It's quite different from what I'm used to doing.

volfpeterOP1y ago

Yeah, the renderer itself must be async to enable async tooling, but everything else can remain sync unless async is really needed.

Regarding data fetching (it's a recurring theme in the comments), I'd probably do most of my async business logic in my routes (well, I'm obviously using htmy with FastAPI and HTMX through FastHX), and components may fetch additional resources if they need something other than the route's result (translations, markdown, html snippets, some other IO).

I'm not sure if any other tool really enables this pattern, but I'm quite curious to see how I'll use it in future projects, and hopefully also what ideas and patterns others come up with in their projects. There's definitely room for creativity.

j / k navigate · click thread line to collapse