Template partials look good, which is one of the key reasons frameworks like React are as good and popular as they are, because you can reuse small segments of code.
I like this approach. I am especially drawn to the idea of making custom components this way but every time I have experimented with this I get burned by the context which has to be passed down through all functions.
A jinja/django template has an implicit context but for nested functions you really have to pass that context down through every function call.
It inevitably ends up just a big dict blob.
You get some typing support in an IDE but nothing really for function parameters.
iommi is wroth mentioning here. It is different from an HTML generator, but one of the things it does is greatly reduce the amount of HTML you need write.
Yeah, I agree, I find them hard to read. JSX is the best thing I've used. Elsewhere in the thread someone mentioned Cotton which seems to strike a different balance.
To be honest my main problem with templates is they have to be one per file. In principle there's no difference between naming a new file and naming a function, but in practice it just sucks. It's a higher barrier so people are less likely to write smaller components, and refactoring support completely sucks. Even renaming a template is a massive pain whereas renaming a function with decent LSP support is easy.
JSX hits that perfect balance between readability while still being regular functions. Maybe something is possible with the new 3.13 template strings?
>For nearly all cases, Django’s built-in template language is perfectly adequate. However, if the bottlenecks in your Django project seem to lie in the template system and you have exhausted other opportunities to remedy this, a third-party alternative may be the answer.
>Jinja2 can offer performance improvements, particularly when it comes to speed.
I do a check for `request.htmx` in my views and conditionally return a template partial as needed. This reduced my need for one-off view functions that were only returning partials for htmx. Works pretty well from my experience.
Partialdef inline is the real win. Lets you define parts of a page without needing to place them in another file. Reduces the mental overhead of imagining how the inclusion will look because it’s already there.
The use case is mainly driven by htmx where you will have lots of these partials and the view code renders them as individual responses.
It's just syntactic sugar, making life a bit easier for HTMX users (cf. "htmx was the main motivation for this feature").
I'm using Unpoly and I just render the whole page and let Unpoly swap the content according to the target selectors, so no need for this. Not much difference in perf if you dont generate gigantic pages with heavy header/footer.
Yeah, but I was doing the same thing 10 years ago with include mixed with extends and blocks. I can just include a file inside a template or render it directly.
you're kinda right, {% partial ... %} vs {% include ... %} is not a big difference, but my mind was vaguely thinking that "includes" have often been seen as large templates, whereas partial have been after the component era with the idea of making small blocks. (my 2 cents)
