django_component + alpine-composition for Vue-like syntax and behavior

[JuroOravec]

Hey, I'm one of maintainers on django_component, and I'm porting Vuetify to Django + Alpine (Working name Alpinui).

Such migration is possible, because Vuetify is built on top of Vue's reactivity system. ...And so is AlpineJS. So I rewrote all the Vuetify components, so the JS logic can be used both by Vuetify (Vue), and by Alpinui (AlpineJS).

To make the above possible, I made a few AlpineJS plugins, so that:

• One can use Vue reactivity (ref, computed, watch, ...) inside AlpineJS components - See alpine-reactivity
• AlpineJS components can be written similarly to Vue components - with props and the setup function - See alpinui-composition
• AlpineJS components have the provide/inject feature - See alpinui-provide-inject

Moreover, over the past few months, we've also added features to django_components that make its templating close to on-par with Vue. There's scoped slots, provide/inject, etc. And soon also spread operator, expressions for prop values, dynamic components and slots, etc.

And so, I'm finally getting to the point - With the above setup, one can achieve much of what Vue offers. At the same time, I currently focus only on the UI / templating part of the stack. Things like making server calls from the client, or keeping server state, is outside of my scope. But that's where Tetra comes in.

So I'd love if Tetra could use the stack above, so users could have a full vue-like experience, while still being able to benefit from Tetra's server features. So like what NuxtJS is to Vue.

I didn't go thoroughly through Tetra's source code yet, so I'd be interested to hear how Tetra works, whether it somehow intercepts the django or alpine components. So I'd be thankful if you'd give me some pointers around.

[nerdoc]

That is a great idea. In fact, I was using django_components before and I think it's a great library. I had a journey through I think all Django-enabled frameworks, including Unicorn, django_component, django_components, djhtmx, reactor, etc.
But finally settled on tetra because I think it has an extremely cool code base. And I think that that is exactly what is missing in the Django world: a framework that uses webcomponents or webcomponent-like components (in terms of usage), but without the Javascript hassle.

I must admit I dislike Javascript a bit because I am not good at it...

So I happened to be the maintainer of Tetra - the whole bunch of heavy original work did Sam Willis, who is unable to continue working on the project due to lack of time.
I drew a call graph of what happens in depth on the python side when someone calls a method in a component:
https://www.figma.com/board/s36Pc4HG52ASTgoE2PcKNB/Tetra-call-graph
Maybe you can see a few things there how it works. It at least helps understanding how Tetra handles the logic - it's not always easy - but it's clear once you get into it.

And to have Vue-like experiences in Alpine would be really a cool thing.

At least I think that implementing Tetra's state logic into django_components would be a (too?) high effort - as Tetra's BaseComponent basically is the same as a d_c's component, without any state.
While Tetra and django_components do things a bit differently under the hood when rendering templates, I think that I would be worth thinking even about collaborating (or even merging) such projects - I always hated the diversity of many projects, instead of working together and bundling forces (look at django/bootstrap5 packages).

Like I said, I don't have much experience in Js developing, I'm more the backend guy, and I am way more fluent in Python than in Js.

So, whatever I can do to cooperate, I'l love to.

[nerdoc]

I also like the idea of collaborating, making the ecosystem nicer for everyone, rather than making people choose A or B.
:thumbsup_

* Loading scripts / CSS from the browser (I implemented that for DC just last week and will be in the codebase maybe next week)

This is done very nicely in Tetra. you add a script as css|script attribute to the component class, and Tetra does the rest. As stated below, it just concats it, no preprocessing yet.

* Differentiating between args and kwargs in components. Funnily enough,  in DC there's a way to specify dictionary items as `prop:key=value`. Which, if I understand correctly, it's the same as the `attrs:` or `context:` prefixes.

Seems so. I must admit that I always have to recheck how attrs: and context: is used as it seems not to be extremely intuitive - but I think it is thought very carefully by Sam Willis (the original author), to separate the outer context from the inner one (and save memory).

* allowing self-closing components with `/`

This is really great. Even If I for myself find the "@" tag a but cumbersome, and I am inclined to change that. I must admit that DC is more intuitive with component "foo-bar" - IMHO ideally would be component FooBar - without quotes, and with the original camelcased class name - it's just easier to remember and less error-prone - I hated that in Unicorn - you have to get all the names right and convert the names in your head, just to satisfy the framework. What also would be easier to use (less words to write) would be a single char like C or T.

{% T Calendar date="2015-06-19" /%}
{% C Calendar date="2015-06-19" /%}

For Tetra, I'd like the T most. The @ is a problem as it is no valid identifier for e.g. PyCharm and tends to produce "errors":

From what I've seen so far, it looks like the two libraries should be compatible.
Definitely.

One thing which I wasn't sure how it works was the build step for js and CSS, like minification and such. Is that applied only to the dynamically generated scripts, or all? That's one thing we can consider for DC. Currently the component's JS and CSS is sent as is. Ideally i there would be an option to apply the same kind of preprocessing as the other static files. But tbh don't know how that works in staticfiles.

It would need a manual step, or automated in build/runserver.
Tetra has some internal Js (tetra.core.js) that is minified/sourcemapped by a esbuild task manually in a script, and the minified script is then just copied into Tetra's static directory.

Tetra also hijacks the runserver mgmt command and adds a build step for the components you write. Sam stated that it would need to get some love as it recompiles the files with every server reload, which could be very high load with many files. This could definitely be improved (just rebuild Js if something's changed) - but Here are my limits: I am not a very experienced Js developer, and I definitely hate webpack (because I am too dumb to use it correctly maybe). Tetra uses esbuild which seems to be easier and faster than webpack, but I still would need very much time to configure that correctly.

But yes, I would be great if e.g. Tetra could just snap all needed Js parts together and bundle it into a few chunks as needed.

I also wrote a plugin system for Django (GDAPS) that works very nicely together with components - and especially here it would help to bundle Js together into a treeshaked, minified package that could be distributed alongside a plugin. But that needs someone smarter than me (or someone with more time, as my day job is treating patients ;-) )

Also in one of the classes, maybe the one that implemented the "public" methods, there were some watchers, (do_watch). I haven't seen it used anywhere. How does that work?
Have a look at the docs - they are quite explanatory here. .watch is extremely helpful.

I think the way to go is:

• Computers and networks are fast enough to keep state on the server for most cases. Until now, noone could convince me of something else (even if Vue/Svelte/React are great - but tend to be monolitic frontends, plugins are more difficult to build)
• If something is too slow with the HTTPS roundtrip, use Alpine to keep the fast moving parts on the frontend.

I may be wrong on the long term, but I'll try this path.

[JuroOravec]

Differentiating between args and kwargs in components. Funnily enough, in DC there's a way to specify dictionary items as prop:key=value. Which, if I understand correctly, it's the same as the attrs: or context: prefixes.

Seems so. I must admit that I always have to recheck how attrs: and context: is used as it seems not to be extremely intuitive - but I think it is thought very carefully by Sam Willis (the original author), to separate the outer context from the inner one (and save memory).

One other benefit of separating the outer and inner context (AKA why I added it to DC) is more predictable behaviour / easier debugging, as you get the guarantee that only the inputs passed to the component can affect the component's output. Because in vanilla Django it's not the case.

---

allowing self-closing components with /

This is really great. Even If I for myself find the "@" tag a but cumbersome, and I am inclined to change that. I must admit that DC is more intuitive with component "foo-bar" - IMHO ideally would be component FooBar - without quotes, and with the original camelcased class name - it's just easier to remember and less error-prone - I hated that in Unicorn - you have to get all the names right and convert the names in your head, just to satisfy the framework. What also would be easier to use (less words to write) would be a single char like C or T.

{% T Calendar date="2015-06-19" /%}
{% C Calendar date="2015-06-19" /%}

For Tetra, I'd like the T most. The @ is a problem as it is no valid identifier for e.g. PyCharm and tends to produce "errors":

Yeah, maybe in the future the quotes in DC's components could be dropped. Because we don't treat the component name as the rest of the kwargs, so the quotes serve no purpose anymore.

Btw, you should be able to name components as FooBar if you want, e.g.

{% component "FooBar" / %}

Moreover, DC allows users to customize what tags need to be called to render the component.

E.g. out of the box we support two:

{# with "component" keyword + name #}
{% component "FooBar" %}
{% endcomponent %}

{# with just the name #}
{% FooBar %}
{% endFooBar %}

So also either of these are possible:

{% T Calendar date="2015-06-19" /%}
{% C Calendar date="2015-06-19" /%}

See https://github.com/EmilStenstrom/django-components#customizing-component-tags-with-tagformatter

Altho if we get as far as to making an language support / intellisense for django components, then in that case it might be better to use one of the two supported formats.

---

One thing which I wasn't sure how it works was the build step for js and CSS, like minification and such. Is that applied only to the dynamically generated scripts, or all? That's one thing we can consider for DC. Currently the component's JS and CSS is sent as is. Ideally i there would be an option to apply the same kind of preprocessing as the other static files. But tbh don't know how that works in staticfiles.

It would need a manual step, or automated in build/runserver.
Tetra has some internal Js (tetra.core.js) that is minified/sourcemapped by a esbuild task manually in a script, and the minified script is then just copied into Tetra's static directory.

Tetra also hijacks the runserver mgmt command and adds a build step for the components you write. Sam stated that it would need to get some love as it recompiles the files with every server reload, which could be very high load with many files. This could definitely be improved (just rebuild Js if something's changed) - but Here are my limits: I am not a very experienced Js developer, and I definitely hate webpack (because I am too dumb to use it correctly maybe). Tetra uses esbuild which seems to be easier and faster than webpack, but I still would need very much time to configure that correctly.

When it comes to the internal JS, we will be now doing a similar thing, just using Rollup instead of ESbuild.

Hm, I don't think I've seen how Tetra hijacks the runserver mgmt command. Where is that defined? And what does it do, does it pre-process the JS, or something else?

Moreover, this also made me realize that when it comes to how DC handles the JS, DC could allow collectstatic to pick up the inlined JS scripts, e.g.

class MyComp(Component):
	js = """
		console.log(123)
	"""

...And yeah, I also mostly just google or use ChatGPT when it comes to working with such build tools 😄 It's hard to know how it works when one uses it only once in a while.

---

I also wrote a plugin system for Django (GDAPS) that works very nicely together with components - and especially here it would help to bundle Js together into a treeshaked, minified package that could be distributed alongside a plugin

Is that tightly linked to Django, or could it be used also without Django?

While I want to add plugins to DC, I have a small dream that DC v2 could be used with other frameworks, not just Django (e.g. similarly to ReactPy).

or someone with more time, as my day job is treating patients ;-)

So I just looked at your profile where it says you're a GP and hobby programmer, and I have to say this is truly admirable! Wish there was more people like you!

I think the way to go is:

• Computers and networks are fast enough to keep state on the server for most cases. Until now, noone could convince me of something else (even if Vue/Svelte/React are great - but tend to be monolitic frontends, plugins are more difficult to build)
• If something is too slow with the HTTPS roundtrip, use Alpine to keep the fast moving parts on the frontend.

I may be wrong on the long term, but I'll try this path.

I don't think it's necessarily about the speed. Just this week I had to move a piece of UI from Django/Python to Alpine/JS, because there was one component where about 2/3rds of it was fine being defined in Django, but 1/3rd needed to be handled in Alpine. And so I had to refactor the whole thing to use Alpine, so things communicate properly with each other (sendings events up and whatnot).

But I can imagine that my use case could be possibly done purely in Django if:

1. I had support for HTML fragments - so replacing only the relevant bits in the HTML
2. Loading of a fragment would run the associated JS (so running JS per instance)
3. If I used something like Tetra to trigger the public methods (currently I use REST approach)

I'm going off topic here, but the use case I keep thinking about which would be hard to do with the setup above is following:

• Imagine I have a component, let's call it "Parent"

• Parent contains another component "List", a list of items.

• User can click "add item" button in the "List" component. This re-renders the "LIst" components, with one more item added.

• But actually, "Parent" doesn't contain only the "List" component, maybe it contains other input fields. And it also includes a text which is derived from the number of list items there are (e.g. items in a shopping cart).

   <div>
   	Create account or continue as a guest?
  
   	<input name="name" />
   	<input name="email" />
   	<input name="password" />
   	<input name="repeat_password" />
  
   	Your shopping cart contains 5 items:
  
   	<!-- List component -->
   	<ul>
   		<li> Item 1 </li>
   		<li> Item 2 </li>
   		...
   	</ul>
   </div>

  Since I'm using state from List inside Parent, then ideally I'd re-render Parent, so all state is updated simultaneously.

  However, Parent contains sensitive info like password, which I would not want to needlessly pass around just to update the UI.

  So what I would want instead is a way to send a message to Parent, when the List component updates. That way, I could re-render just List, keep the sensitive info untouched, and Parent would be still updated about the number of items in the list.

• So this brings me to the conclusion that in DC, we should implement also event emitting, e.g. like in Vue.

  So in a component's JS, one could call $emit(), e.g.

   @register("my_comp")
   class MyComp(Component):
   	js = """
   		const itemsCount = $data.items.length;
   		$emit('updateItemsCount', itemsCount);
   	"""

  Which the parent component could listen to by specifying a listener in the Django template, e.g.

   <div>
   	{% component "my_comp" @updateItemsCount="handleItemsCount" / %}
   </div>

  Where updateItemsCount would be function defined in the JS of the Parent component:

   let count = 0; // Initial count
  
   $on("handleItemsCount", (newCount) => {
   	count = newCount
   });

[nerdoc]

{% component "FooBar" %}
{% endcomponent %}

{# with just the name #}
{% FooBar %}
{% endFooBar %}

I like these two - Tetra has a shorthand "@", but I think it makes code less readable.

See https://github.com/EmilStenstrom/django-components#customizing-component-tags-with-tagformatter
This is great, but allows programmers to be less "defaulting" - I thint it woul be good to NOT encourage everyone to use his/her own prefix...

I also wrote a plugin system for Django (GDAPS) that works very nicely together with components - and especially here it would help to bundle Js together into a treeshaked, minified package that could be distributed alongside a plugin

Is that tightly linked to Django, or could it be used also without Django?
It's linked to Django tigthly, aims to be a simple to use plugin system in Django, without much configuration.
Really works well, even if documentation could be better.

While I want to add plugins to DC, I have a small dream that DC v2 could be used with other frameworks, not just Django (e.g. similarly to ReactPy).
Hm, there is already pluggy (which does not rely on Django) which provides plugins. But I think the syntax is a bit weird. I wanted to have something more pythonic.

But I can imagine that my use case could be possibly done purely in Django if:

1. I had support for HTML fragments - so replacing only the relevant bits in the HTML

That's what I'd like to add to Tetra too. HTMX does this very nicely.

2. Loading of a fragment would run the associated JS (so running JS per instance)

Also easy in HTMX. Benoit Blanchon has nice tutorials about using the message framework with HTMX. This approach (hijacking messages in the middleware, and running Js code when a component is updated) is great.

3. If I used something like Tetra to trigger the public methods (currently I use REST approach)

Yes, before Tetra, I used HTMX and DC, and it needs some rethinking if you want to change the application from a HTML-request/response with some REST/HTMX/etc. syntactic sugar in components - to a component based approach (which is usually used by React/Vue etc.)

But, at least ended up with much less (and more readable) code, as component based thinking is human native it seems. And as good as HTMX is, technically, it forces you to write Django views for every simple change, click and "component" update. This may be perfect if you use 95% request/response and very few "reactive updates" on your page. But when creating a bigger application, and you need a component based approach, you get stuck soon in spaghetti code with all the HTMX views.
In Tetra, you just add one @public method to a component, and directly do the things you need there, HTML update afterwords is for free.

[nerdoc]

I'm going off topic here, but the use case I keep thinking about which would be hard to do with the setup above is following:

* Imagine I have a component, let's call it "Parent"
* Parent contains another component "List", a list of items.
* User can click "add item" button in the "List" component. This re-renders the "LIst" components, with one more item added.
* But actually, "Parent" doesn't contain only the "List" component, maybe it contains other input fields. And it also includes a text which is derived from the number of list items there are (e.g. items in a shopping cart).

[...snip...]]]

  Since I'm using state from `List` inside `Parent`, then ideally I'd re-render `Parent`, so all state is updated simultaneously.
  However, `Parent` contains sensitive info like `password`, which I would not want to needlessly pass around just to update the UI.
  So what I would want instead is a way to send a message to `Parent`, when the `List` component updates. That way, I could re-render just `List`, keep the sensitive info untouched, and `Parent` would be still updated about the number of items in the list.

In Tetra, you can do that using in a public python method:

class MyComponent(Component):
    @public updateParent(self):
        self.client._parent.do_something()

Have a look at the _parent attr docs.
Maybe this is what you need.

In terms of object encapsulation, I don't like this approach, as the child should not really know about what the parent offers. There are different approaches here too. One is the emitting of signals which bubble up in the DOM and bring the parent to doing something. This could be easily done using Alpine IMHO and implemented in Tetra.
But the self.client._parent.foo_bar() approach has some benefits too. It could be seen as a hook where parent components "offer" a certain method to children, and they can call it.

Events approach:

• The ChildComponent on the toilet cries "finished!" after doing poop(), and DadComponent hears that and takes some action: He goes to the ChildComponent (after finishing the dishes) and cleans it's bottom.) 😆 But it could be that MomComponent also heard the "finished!" event, and comes too.

Parent callback approach:

• DadComponent offers the ChildComponent a device with a button and tells him before going to the toilet: when you press that button, I will come and clean you up.

The difference is: in the second approach the child knows what exactly happens when he presses the button. It's the handle the parent component gave him before.
In the first, the child just says "finished!", and whoever my concern it, MomComponent, DadComponent, or NannyComponent will react to it - the child does not know that before.

I've seen this (second, Tetra approach) in a Js framework too IMHO, but cant remember where, or at least read about it somewhere.

As always, it's about documentation ;-)

  Which the parent component could listen to by specifying a listener in the Django template, e.g.
  ```
   <div>
   	{% component "my_comp" @updateItemsCount="handleItemsCount" / %}
   </div>
  ```

The main problem here is a Django syntax one. Vue components (in fact, HTML tags) can be speead over multiple lines. Django template language does not allow that, so this is not legal:

{% component "FooBar"
    title="Baz"
    content="Foosdofksodf"
  %}

Only one-liners allowed. Which forces us to keep things as short as possible. 🤦

  Where `updateItemsCount` would be function defined in the JS of the Parent component:
  ```js
   let count = 0; // Initial count
  
   $on("handleItemsCount", (newCount) => {
   	count = newCount
   });
  ```

But have a look at the nested counter at https://tetraframework.com - in this example, at least child items are updated when parents are updated. But this is clear.

[nerdoc]

Hm, I don't think I've seen how Tetra hijacks the runserver mgmt command. Where is that defined? And what does it do, does it pre-process the JS, or something else?

Ah, just look at tetra/management/commands/runserver.py
The actually code is in build.py (wrapper) and library.py.