Some food for thought

[Tobi-De]

Sorry, this is not very elaborated
https://www.youtube.com/watch?v=31pBMi0UdYE
https://indieweb.social/@adamghill/113159856844015725

Cotton already make it possible to build a lot of what’s shown in that video, which is great! The missing piece is a component library on top of Cotton to add the Tailwind and necessary JavaScript. Someone with good design skills would also be needed. The potential is huge. Thanks again for creating this!

[wrabit]

Cheers @Tobi-De.. completely agree and the thought-food has been mentally digesting for quite some time already ;) ⚙️

[JuroOravec]

Hi, I was thinking of making a new issue / discussion, but it's relevant to component libraries and whatnot, so I thought I'd comment here.

I was/am frustrated with not having a proper UI component library in the Django ecosystem, so I ported Vuetify to AlpineJS, so it could be used with Django + django-components + AlpineJS stack. The only thing that remains on that front is to rewrite the JSX to django templates and define Python API for the components, and I'm postponing that till django-components has more mature API.

I'm a big proponent of collaboration, people seem to like using HTML tags for components, and @wrabit you seem to be very active! So I'd love if we could coordinate somehow? :)

There's still a lot to be built for the Django frontend ecosystem:

1. In terms of templating I feel like django-components is mostly complete, with the exception of HTML-like syntax like django-cotton has.

2. django-components allows to write JS and CSS that's specific to a component, similarly to Vue. But right now the JS/CSS is static - it runs only once, and there's no way to configure it based on component's Python props. I'm currently adding support for JS / CSS variables, AKA passing data from Python to JS/CSS. So each component instance could receive different JS/CSS vars, similarly to how component instances can receive different props. Plus I'm also adding support for scoped CSS. So overall a lot of inspiration from Vue.

3. One big reason why I'm writing this is that I'd love to have intellisense for the components inside django templates. Easiest way for that would be to take Vetur language server, and modify their parsing logic and whatnot.

   • It wouldn't be that hard to support just different ways of wrapping the components (AKA whether {% %} or <>). But if the components actually had different syntax and different ways of defining props, slots, etc, then those two flavours would have to be implemented separately.

   • Here the issue with django-cotton is that it doesn't explicitly define the props (kwargs) and slots. So it would be difficult and error-prone to implicitly extract the component props from the component's Template object. On the other hand django-components supports typing the components, which could be used by the language server to know which components accepts what kwargs and slots.

   • I'd also love the intellisense to have also support for JS-side variables and events, e.g. that it'd raise an error if one tries to pass down to a child component a JS variable that was not defined in the parent component. Tho, this is several steps ahead, I'm still just building a support for CSS and JS vars with components.

4. I also want to integrate django-components with Tetra. You can see on the source code that Tetra was written really well. And it has a lot of similar design choices as django-components. So Tetra could be re-written to be built on top of django-components and provide the "frontend-backend interaction" layer.

   • One thing that I find lacking in Tetra (and similar Livewire-like libraries) is that they work with the concept of HTML fragments (AKA something happens and some section of the HTML gets replaced), but they don't provide a way for client-side JS to react to these changes. So one is then forced to solely rely only on the HTML fragments to add interactivity to the page, and one needs to fetch the new HTML from the server even if user's action doesn't require any new data / processing, which needlessly bloats the server's API.

     In contrast, for django-components, I want to add a support for 1) running JS code per component instance (so it would run some component's JS logic even if an HTML fragment was inserted), and 2) JS-side event handling system, similar to Vue.

     I found that with those two, we'd have a really powerful setup where one could fetch HTML fragments from the server to fetch new data, but then easily add interactivity via JS.

     E.g. imagine you have a cart / checkout page on an eshop, and you would insert an item into the cart list as an HTML fragment. And when the fragment loads, it then runs the component's JS code, which emits an event with the item's details. The parent component, the cart list, would receive the event and could update its state and display the updated total price.

5. Since the Vuetify port is built on AlpineJS, there are also a few improvements to make django-components integration with AlpineJS better. E.g. that slots would have access to the same AlpineJS variables as the HTML outside of the slotted component. Tho these will have to be defined as standalone plugins.

6. So, for django-components to work with Tetra, django-cotton or AlpineJS, there needs to be a plugin system, whereas the plugins would be able to:

   • Pre-process component's Template (This is where django-cotton could fit)
   • Modify the behaviour of component or slot tags
     • E.g. for the AlpineJS integration, I'd like to define "Alpine-enabled" slots with an alpine keyword, {% slot "my_slot" alpine %}. So the plugin would detect and remove the keyword, and then modify the Template based on the presence of the keyword.
   • Add extra funcions or metadata to the per-instance JS (This is how the event handling system could be implemented)

7. I have a working demo for adding support for TypeScript / Sass. I'd also like to add markdown to the mix. So overall the idea would be that the associated HTML, JS and CSS files could be defined in different flavours and pre-processed, and users could plug in custom pre-processors. The JS and CSS pre-processing could happen at collectstatic or at server start. But the markdown-to-html conversion would operate on the rendered template, so at render time.

8. This is a minor thing for me, but Tetra supports i18n by allowing to extract translation strings from I think the HTML. This would make more sense to be defined in django-components.

---

Sorry for the wall of text, but wanted to share what's brewing. @wrabit I'd love to hear what are your thoughts - on the points above, on where you want to take django-cotton, and whether we could make it play well together.

---

PS: Sorry if some bits are too technical, let me know if some things are not clear, as I may be too deep is some topics.

[JuroOravec]

Moreover, here's how the "components with HTML tags" and "components without Python class overhead" could be implemented in django-components.

TL;DR, there'd be Vue-like single-file components (SFC) files that would be clearly distinguishable from regular HTML, e.g. by giving the SFC the .comp suffix. And then inside the .comp files people could configure whether to use Django or HTML tags for the components like so:

<template tag="django">
  {% component "button" href="/page/save-form" %}
    Click me!
  {% endcomponent %}
</template>

Vs

<template tag="html">
  <c-button href="/page/save-form">
    Click me!
  </c-button>
</template>

[wrabit]

@JuroOravec sorry for the humungous delay. I personally have desire to lean more on the side of simplicity with cotton (as much as possible), as least for now until it's stable and that it includes the base set of features I want. I use it for a few work projects alongside an HOTW (html over the wire) framework that mirrors livewire's api and for my usecases, it's fine.

Reading through some of your points, some things come to mind:

Regarding the desire for more js interactivity (vs html partial diffing) you can get some distance using livewire's alpine magic '$wire' which proxies function calling and property getting/setting. So you might be able to achieve a decent amount of functionality outside of the html partial stuff building something similar to that. But I also think part of the attraction and ease of HOTW is the cohesive mental model presented to developers, that they don't have to venture too far into new paradigms to build something reactive. Yes it, it comes with some quirks at times, but I can't for now see how that can be resolved easily with another approach adding complex js api / SFC setup - whilst keeping this model high in DX. (prove me wrong though). It was bliss for me spending 5 years building across client/server, then coming to the HOTW model, so it's not something I am keen to replicate.

I do have some other thoughts on things loosely related to the subject but here is not really a place for it, maybe we can pick things up on X/twitter.

[JuroOravec]

@wrabit No prob at all! Thanks for mentioning $wire, had a brief look and it will be a good reference point when dealing with the HTML partials / fragments.

But I also think part of the attraction and ease of HOTW is the cohesive mental model presented to developers, that they don't have to venture too far into new paradigms to build something reactive. Yes it, it comes with some quirks at times, but I can't for now see how that can be resolved easily with another approach adding complex js api / SFC setup - whilst keeping this model high in DX. (prove me wrong though).

Yeah, we will see. My drive is to have something in Django / Python where I can build as intricate and robust UI as I can in Vue / React. And for that the ability to drop down to JS is definitely needed, e.g. if I wanted to use some library that uses <canvas> for rendering some visualizations. But for average users, both JS and CSS would still be optional.

And whether there'd be something similar to $wire and how powerful that side of things would be would depend on whether someone else would drive that.