"out-of-bands" variable changes, like htmx' hx-swap-oob or event cross-bubbling

[nerdoc]

I want to start a discussion about how to deal with "external" variable changes, like it is possible in HTMX using hx-swap-oob.
I often need to change something in the DOM, which is outside of the current scope (=component). Let#s imagine a component like the todo list that is part of a page. I'll simplify the page template like this:

{% extends base.html %}
{% load ... tetra %}

{% block page-title %}<div id="page-title">Sample TODO list - {{ count }} items</div>{% endblock %}

{% block content %}
  {# ... some html #}

  {% @ todo_list / %}

  {# ... some html #}
{% endblock %}

Now let's say I want the page title to update every time the todolist adds or removes an item. With the current setup this is not possible. (It's also not possible with Django-Unicorn or sockpuppet. Only turbo-django offers a way to more or less complicatedly stream HTML over the wire to somewhere into the DOM)

But I think this is a quite common need in development, to update other variables than the current component's.

I know, this is not really a well-designed approach, adding a{{count}} variable outside the component that relies on the component. But it's only an example. To solve this, it would be a possibility to make a parent component that covers the whole page (in base.html) and has a {% block 'default' %} which contains other blocks, so events can bubble up the dom and would change the "count" variable in the parent.
But, this puts the components in direct contact, or even dependent on another.

What I would like to have is some kind of "loose coupling", like Django signals are doing. in e.g. Qt5 (the C++ framework) this is even better, Javascript has their events etc.

AFAIK, Tetra has the dispatch() method to do this - but it has to be parent element that receives that event - not all elements in the DOM receive those events.

Is there a possibility how to solve this (IMHO common) problem - to update another part of the DOM when receiving an updated component HTML?

I have some ideas, don't know wether they work, I did not get them to work correctly:

Parent talk

Generate a Page component with a default block that contains all other stuff, including a todo component.

{% @ page pk=page.pk %}
  ...
  {% @ todo_list .. / %}
  ...
{% /@ %}

I think this does not work with current django's blocks & extending them. Calling self._parent.set_page_title() would be the way to go there, but the component has to know where in the tree it is. (call self._parent.set_page_title()? or self._parent._parent.set_page_title()??)

So this method would not scale well.

AlpineJs' $dispatch

<div x-data="{ title: 'Hello' }" @set-title.window="title = $event.detail">
    <h1 x-text="title"></h1>
</div>
<div id="somewhere-else-in-the-DOM,-maybe-in-another-django-block">
{% @ foo / %}
</div>

Mind the .window modifier. This ensures that the event listener listens at the window, not the current tag.

class Foo(Component):
    title = public("a title")
    def save(self):
        ...
        self.client._dispatch("set-title", {"title": self.title})
    template = """
        <button @click="save()">Save method call</button>
        <button @click="$dispatch('set-title', 'new title')">Set title using AlpineJs</button>
    """

Here, the second button works as intended. The first one, calling _dispatch() from the backend docs here, generates an object like this

{
  title:  {
    _component: {
      title: "foo"
    }
  }
}

The Tetra documentation is incomplete here.
I don't understand how to use that in the receiving object. I can't do a @set-title.window="title = $event.detail._component.title", and this would be ridiculous. An "extended JSON serialisable object" is unclear. Alpine docs say "This data will be accessible as the .detail property of the event" - but I can't access .detail anywhere.

Any ideas to simplify this procedure?

@public.listen decorator ❤️

Components would have to implement Alpine's x-data and @custom-event automatically, e.g. when using a (to be implemented) @public.listen() decorator.

class MyComponent(Component):
    title = public("")
    
    @public.listen("set-title")  # <-- this would be a new "listen" modifier for public.
    def set_page_title(self, title):  # or "event" as parameter etc.
        self.title = title
    template = """<!-- the component needs to implement the correct x-data attributes automatically -->"""

class AnotherComponent(Component):
    def do_something(self):
        ...
        self.client._dispatch("set-title", "a new title!")

This way the loose-coupling would be addressed. A component could send a simple Js event, and another component could automatically receive it using a listener on .window.

@samwillis, Please tell me what you think about that.

[samwillis]

Lots of good thoughts here, and you are on the same track as me.

I have been torn on implementing a @public.listen as I don't want to duplicate too much behaviour that can be achieved already with plain Alpine. Initially I was going to do a @public.on() that mapped to a x-on/@ Alpine directive on the root element of the component, as you suggest. But as that is possible with just adding it to the template I haven't until now.

Your @set-title.window implementation is exactly what I would suggest, however you are right the self.client._dispatch() is doing something odd. It should behave have produced this:

{
   _component: {/* The alpine component that dispatched the event */},
   title: "foo",
}

The offending code is here:

https://github.com/samwillis/tetra/blob/593a14a395c0f7a35db1c276ef5ddce897a199f0/tetra/js/tetra.core.js#L69-L74

I will have to take a look again in the morning post-coffee.

However, maybe we should have a @public.on() that auto maps, with all available modifiers, to x-on on the root element...

Going back to your original problem though, setting a variable in the title. Something I want to explore is how to integrate with Alpine.store, I think it could be a really useful way of create a global state sore for exactly that sort of thing. I don't yet have a plan though.

[nerdoc]

ok, thanks. Alpine.store looks nice for just using Alpine. But doesn't it duplicate the "store" on the Django side? It would be easier to store the state in the backend, and have a single source of truth...?

[nerdoc]

Ah yes, and a @public.on() would be a convenient and flexible way to put that right.

# in a component
@public.on("set-page-title.window")
def set_page_title(self, event):
    self.title = event.detail.page_title

# in another component
def foo(self):
    self.client._dispatch("set-page-title", {"page_title": self.title })

I just thought about making it even easier as this is a very common use case:

• something like self.emit(event, data) as wrapper for self.client._dispatch(event, data) (or another name)
• @public.on("set-page-title", window=True)
• reform the event parameter into direct data access, rename it to "data" - so you can use data.page_title instead of event.detail.page_title(possible disadvantage: no access to other object properties of event like ".target" etc.

[samwillis]

Exactly, but we could have a "shared store" that can be initiated from the server, and then have all its public attributes sent with all requests to component public methods.

So from a public method you would be able to access it with:

@public
def my_method(self):
    self._stores.myStore.title = 'Something'

Not sure how to define a store yet, I think it may end up being similar to a component, with public methods and properties.

As I said, early thoughts.

[nerdoc]

ok, this would be even cooler.

[gsxdsm]

Wanted to pick this back up this is a common issue I run into. If there is a consensus on the approach and api I can pick this up and start to prototype an approach.