Understanding UI Libraries and components reusability

[LuisHPorras]

Hi everyone, I’m new to Django and I’m not sure if the topic I want to discuss properly fits here but seemed to me the best place.

I’m working in a project that uses Django + HTMX and the team has chosen Flowbite (not really relevant) as the UI components library. I have experience with libraries like Vue and React and I’ve had a hard time understanding that Flowbite “only” (I know its a lot) provides the JS functionalities for the “components” described in their documentation.

The question I have is:

“Isn’t it a common practice in the Django environment to have a library or self defined set of abstract components like Vuetify or Ionic for example?”

Example: dropdown.html template would have it’s self defined template vars like: items, selected item… and all the styles (Tailwind classes) and js (I understand this is what Flowbite provides wheter through vanilla js or htmx…) is configured only once. Then when we whant to use a dropdown in our app we would have to use something like {% with myCustomOptions as items…%} so that we can reuse the components without having to rewrite the in each template.

dropdown.html

<div>
    <button id="dropdownDefaultButton" data-dropdown-toggle="dropdown" class="text-white bg-blue-700 hover:bg-blue-800 focus:ring-4 focus:outline-none focus:ring-blue-300 font-medium rounded-lg text-sm px-5 py-2.5 text-center inline-flex items-center dark:bg-blue-600 dark:hover:bg-blue-700 dark:focus:ring-blue-800" type="button">
        {{ item_selected }}
        <svg class="w-2.5 h-2.5 ms-3" aria-hidden="true" xmlns="http://www.w3.org/2000/svg" fill="none" viewBox="0 0 10 6">
            <path stroke="currentColor" stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="m1 1 4 4 4-4"/>
        </svg>
    </button>
        
    <!-- Dropdown menu -->
    <div id="dropdown" class="z-10 hidden bg-white divide-y divide-gray-100 rounded-lg shadow-sm w-44 dark:bg-gray-700">
        <ul class="py-2 text-sm text-gray-700 dark:text-gray-200" aria-labelledby="dropdownDefaultButton">
            {% for item in items %}
                <li>
                    <a href="{ item.url }}" class="block px-4 py-2 hover:bg-gray-100 dark:hover:bg-gray-600 dark:hover:text-white">
                        {{ item.label }}
                    </a>
                </li>
            {% endfor %}
        </ul>
    </div>
</div>

header.html

...
{% with myCustomItems as items %}
    {% include "./components/dropdown.html" %}
{% endwith %}
...

In this sense I’d expect a library like Flowbite to also provide some variables to globally config all the styles of the components, having docs explaining the inner variables of each component and so on…

Am I missing something important here? In case this is something everyone does “privately” for each project and there is no go to library I’m struggling to understand what are the best practices regarding this approach.

[czue]

You’re not really missing anything. This is a very common requirement in Django projects and a bit of a gap in the current ecosystem. My favorite take on solving it is a 3rd party package called django-cotton which might be what you’re looking for.

[carltongibson]

I’m not quite sure “bit of a gap” is fair. To quote the README from one option Dj-Angles (by @adamghill):

Django Component Libraries

There are a growing number of component libraries for Django. A non-complete list:

• Slippers: Build reusable components in Django without writing a > single line of Python.
• django-components: Create simple reusable template components in Django.
• django-template-partials: Reusable named inline partials for the Django Template Language.
• django-bird: High-flying components for perfectionists with deadlines.
• django-cotton: Enabling Modern UI Composition in Django.
• django-viewcomponent: Build reusable components in Django, inspired by Rails ViewComponent.
• django-unicorn: The magical reactive component framework for Django .

That’s not counting dj-angles itself, and likely there are more. I was looking at Htpy only yesterday.

I’d probably describe it as a fertile growth area currently — there are lots of people working on it, which is exciting, but does mean there’s not just one settled option that you should definitely use.

[LuisHPorras]

Thanks a lot for the response, I’ll dig into it

[LuisHPorras]

Wow, that’s fantastic! Thanks a lot, now the hard part, which to choose.

[czue]

@carltongibson

I’m not quite sure “bit of a gap” is fair.

Sorry, I didn’t think that phrasing would be particularly controversial, but you’re right that it’s not a gap in that there aren’t lots of good options—the gap I was referring to is that there isn’t a single, agreed-upon answer or recommendation. Did not mean to imply that solutions/options don’t exist!

[adamghill]

I ended up creating an “awesome” repo for this at some point: adamghill/awesome-django-components - Codeberg.org. If I’m missing any (still maintained) libraries, I’d love a PR.

I do view htpy and similar libraries a little differently – they are more like a way to create HTML from Python. Might solve a similar use case, but they approach it from a different angle IMO. The three of that style I’ve looked at the most are htpy, haitch, and dominate. You can see really simple examples for those three here if you are interested: GitHub - adamghill/django-unicorn-playground: Prototype and debug `Unicorn` components..

[carltongibson]

Semi structured ramblings follow.

@adamghill

I do view htpy and similar libraries a little differently – they are more like a way to create HTML from Python. Might solve a similar use case, but they approach it from a different angle IMO.

That’s right. They’re (let’s call it) code driven, rather than template driven.

They’re very much like how you build HTML up in Elm, and popular derivatives in Rust, and even React. It feels strange stepping away from the template file, but having watched recent evolutions I’m coming round to the idea that code driven might be a good approach for more component-style parts of an application.

e.g. I get a long way with template-partials and a backing view. That composite makes the component to my mind. Folks (coming from frontend) keep pushing for more complex slots there. I find myself torn between saying “You’re holding it wrong — stop trying to do React and write templates” and having the code driven approach from Elm pop into mind. (Recently the FastHTML project has been pleasing people, and follows a similar approach.)

Anyhow…

[vdejager]

Thanks for the discussion. I’m using django-components myself. However, something I might overlook that you might use is a drop-in for assigning many to many relations in forms, something similar to the selection boxes in the django-admin

Does anyone know is something like that exists in one of the UI libs?

[carltongibson]

@vdejager check out @jrief’s django-formset library.

Documentation of django-formsetdjango-formset

Jacob was showing me an enhanced version of just that widget at the DjangoCon Europe sprints last week.

(Edit: I updated my link to match the correct one Jacob gives in his reply below)

[jrief]

This documentation is outdated. Please check the new and interactive one at:

Documentation of django-formsetdjango-formset