Syntax sugar for rendering multiple partials

[AHTOOOXA]

In the end we render all these partials and in a lot of cases multiple partials should be updated. So these is my proposal to make it cleaner by adding something like render_partials(partials=[], context={}), advance the idea of something like render_block_to_string in django-render-block package

I personally sticked to the pattern explained below to solve updating multiple elements with Django + HTMX. It kinda takes on HTMX - Updating Other Content: #Solution 2 and solves it the way no extra templates or request, events and handlers needed

1. I am creating partials with IDs and hx-swap-oob for different page components and different states of these components.
   In example below it is two states of #switch-button and an #order-list
2. In a view.py i handle request do the preparations and context and return HttpRespone of multiple rendered partials and this way they are updated in place without:
   • any htmx events and extra requests #Solution 3
   • without extra .html templates
   • can update as much elements as you want
   • follows locality of behaviour idea

orders.html

{% load partials %}  
  
{% partialdef order-button-active %}  
  <a id="switch-button"  
     hx-swap-oob="true"  
     class="btn btn-dark"  
     type="button"  
     hx-get="{% url 'orders_view_inactive' %}"  
     hx-target="#orders-list"  
     hx-swap="outerHTML">  
      Архив  
    <i class="bi bi-clipboard-check-fill"></i>  
  </a>{% endpartialdef %}

{% partialdef order-button-inactive %}
  <a id="switch-button"
     hx-swap-oob="true"
     class="btn btn-primary"
     type="button"
     hx-get="{% url 'orders_view_active' %}"
     hx-target="#orders-list"
     hx-swap="outerHTML">
      Активные
    <i class="bi bi-clipboard-check-fill"></i>
  </a>
{% endpartialdef %}
  ...
  
{% block content %}
...
  <div class="d-grid gap-3">  
    {% partial order-button-active %}  
  </div>
...
{% endblock %}

view.py

@login_required(login_url="login_user")
@allowed_user_roles(["ADMIN", "MODERATOR"])
def orders_view_active(request):
    steps, orders, leftovers = get_orders_display(is_active=True)
    context = {
        "orders": orders,
        "leftovers": leftovers,
        "steps": steps,
    }
    return HttpResponse(
        render_to_string("core/orders.html#order-button-active")
        + (render_to_string("core/partials/orders_list.html",
                            context))
    )


@login_required(login_url="login_user")  
@allowed_user_roles(["ADMIN", "MODERATOR"])  
def orders_view_inactive(request):  
    steps, orders, leftovers = get_orders_display(is_active=True)  
    context = {  
        "orders": orders,  
        "leftovers": leftovers,  
        "steps": steps,  
    }  
    return HttpResponse(  
        render_to_string("core/orders.html#order-button-inactive")  
        + (render_to_string("core/partials/orders_list.html",  
                            context))  
    )

So I am thinking that adding something like this could be beneficial but don't really know it if follows your idea behind this package

render_partials(templates=["core/orders.html#order-button-inactive", "core/partials/orders_list.html"], context)

which will wrap

HttpResponse(  
    render_to_string("core/orders.html#order-button-inactive")
    + (render_to_string("core/partials/orders_list.html",  
                        context))  
)

[carltongibson]

Hi @AHTOOOXA.

Thanks for the report. Rendering multiple parts (or partials) for a response to handle oob cases is a good approach!

I think I'd just handle this using HttpResponse though. In particular, as well as allowing passing the whole string content, HttpResponse allows usage as both a file-like, so interactively calling write() and with a generator. (See Django's usage docs for HttpResponse)

I think one or other of those would be idiomatic enough, and I wouldn't think it worth it to maintain another shortcut wrapper on top of that.

Here's an example:

diff --git a/tests/templates/child.html b/tests/templates/child.html
index e69de29..2e96b18 100644
--- a/tests/templates/child.html
+++ b/tests/templates/child.html
@@ -0,0 +1,10 @@
+{% extends 'base.html' %}
+{% load partials %}
+
+{% partialdef extra-content %}
+Extra Content
+{% endpartialdef %}
+
+{% block main %}
+Main Content
+{% endblock %}
diff --git a/tests/tests.py b/tests/tests.py
index e9a3a12..ce98a99 100644
--- a/tests/tests.py
+++ b/tests/tests.py
@@ -157,3 +157,34 @@ class ChildCachedLoaderTest(TestCase):
         # Simulate a template change and check the cache is reset.
         django.template.autoreload.template_changed(None, Path(template.origin.name))
         self.assertEqual(len(cached_loader.get_template_cache), 0)
+
+
+class ResponseWithMultiplePartsTests(TestCase):
+    def test_resonse_with_multiple_parts(self):
+        from django.http import HttpResponse
+        from django.template.loader import render_to_string
+
+        context = {}  # Your context here.
+        template_partials = ["child.html", "child.html#extra-content"]
+
+        # Stragegy 1: Combine in view.
+        response_content = ""
+        for template_name in template_partials:
+            response_content += render_to_string(template_name, context)
+
+        response1 = HttpResponse(response_content)
+
+        # Stragegy 2: Use as a file-like object.
+        response2 = HttpResponse()
+        for template_name in template_partials:
+            response2.write(render_to_string(template_name, context))
+
+        # Stragegy 3: Use with a generator expression.
+        response3 = HttpResponse(
+            render_to_string(template_name, context)
+            for template_name in template_partials
+        )
+
+        for response in [response1, response2, response3]:
+            self.assertIn(b"Main Content", response.content)
+            self.assertIn(b"Extra Content", response.content)

I hope that makes sense.

I'm glad you're enjoying the package 🎁

[carltongibson]

See also carltongibson/django-template-partials#43.

As well as the strategies outlined [on issue #90 (this issue)], a TemplateResponse subclass that knew to do the messages.get_messages() dance would stop this logic leaking into the view (but also not require making it middleware based).

It’s something I’m pondering but I think that’s something more view-layer appropriate (so Neapolitan) rather than template-partials itself (which is about the template tags only really).

[kevinrenskers]

I would love to be able to do something like self.template_name = "example.html#test-partial,second-partial", exactly for the same reason: rendering multiple partials as a response to AJAX requests. For example when adding a comment the comments should be updated, as well as the engagement counts located in another part of the template.

[gaeldb]

You can do this with a little Mixin:

class HtmxRequestMixin(object):
    def partials_render_to_response(self, context=None) -> HttpResponse:
        if self.template_partials is None:
            raise ValueError("template_partials cannot be empty, it must be a list of partials names or a single partial name.")
        if not isinstance(self.template_partials, list):
            self.template_partials = [self.template_partials]

        response_content = ""
        for template_partial in self.template_partials:
            response_content += render_to_string(self.template_name + template_partial, context)
        return HttpResponse(response_content)

And then (here in a Class Based View):

    def get(self, request, *args, **kwargs):
        if request.htmx:
            self.template_name = 'contracts_list.html'
            self.template_partials = ["#test-partial", "#test-2"]
            self.context = self.get_context_data()
            return self.partials_render_to_response(self.context)

[carltongibson]

OK, I'm going to move this to Neapolitan. I have an approach I'm using in the work project that I'll look to add there.