Imagine you have 2 big components, one fetches from an third-party API and the other from your backend, this way they can load at the same time instead of sequentially.
I was imagining more like you have a Django view that does all the async data fetching and then you hand off the results to a 'dumb' page component that does only rendering
I guess the point is to have components know how to fetch their own data, particularly when combining with HTMX and having backend return page fragments that correspond to components. But maybe this makes more sense in React than it does when translating the pattern back to server-side?
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...
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.
It seems like the view endpoint would be for functionality shared the full view, like auth safeguards and such, while the components would fetch the data they need; this would make it so you don't need to pass around the data to the view and save a few lines of code; of course this is not compatible with the idea of having "dumb" components vs "logic" ones like people do in React and alike.
Components don't really need to fetch anything, they don't need to be smart. It's up to you where data fetching happens. If you look at fasthx for example, you'll see that routes/views normally handle your business logic and fasthx does the rendering (now with Jinja or htmy). With Jinja for example, it can only work like this. With htmy, you have more flexibility (which can be an advantage but of course it can also be misused).
But does it actually work that way? If I `await fetch_from_api()` in the first component before returning the tree with the second component that fetches from my backend, `fetch_from_api()` has to resolve before Htmy finds out about the second component.
Right, but if this framework enabled that optimization, I’d expect it to have some examples showing how you’d implement it. As far as I can tell, there’s no way to structure your code to allow parallel component rendering with this framework.
With the current renderer (which is super basic because simplicity and features were the main priority over optimization for now), if a component has multiple async children, they will be resolved concurrently. I assume that's what you meant by "parallel". Not sure why that would need an example, but you can simply create a component that calls asyncio.sleep(1), then create a bunch of instances and render them to test it.
I want to have at least the same level of concurrency when the new, better optimized renderer lands.
I guess the point is to have components know how to fetch their own data, particularly when combining with HTMX and having backend return page fragments that correspond to components. But maybe this makes more sense in React than it does when translating the pattern back to server-side?
e.g. same author has this https://github.com/volfpeter/fasthx?tab=readme-ov-file#htmy-... which is doing that, but there's still a 'view' endpoint. Why not put the data fetch code there and have 'dumb' components that don't need to be async?