Showcase: Tab component and template-centric components

[JuroOravec]

With the recent additions, django-components is now getting closer to be on par with React and Vue in terms of templating capabilities!

What I mean is that now it's possible to write complex templates where components are fully defined in the template, meaning that most of the HTML attributes and templating can be colocated. Really excited about this! 🎉

Here's an example of what is now possible with django-components:

{% component "tabs" attrs:class="p-6 h-full" %}
  {% component "tab_item" header="Tab 1" %}
    <p>
      hello from tab 1
    </p>
    {% component "button" %}
      Click me!
    {% endcomponent %}
  {% endcomponent %}

  {% component "tab_item" header="Tab 2" %}
    Hello this is tab 2
  {% endcomponent %}
{% endcomponent %}

Which renders:

While it may not look like much at first, stop and think... How is it possible?!

With simple components, we would assume that each component only renders and inserts a string in its place. Yet, we see that the tab headers (e.g. Tab 1) are rendered in a different place than where they were defined.

What actually happens is that the tabs component uses the information from tab_item components. This is actually a major improvement in how components can be written with django-components.

Previously, to achieve this layout, I had to define the HTML for individual tabs in Python code, and then pass around the pre-rendered HTML as variables:

class TabEntry(NamedTuple):
    header: str
    content: str

tabs = [
	TabEntry(
		header="Tab 1",
		content=Template("""
		    <p>
		      hello from tab 1
		    </p>
		    {% component "button" %}
		      Click me!
		    {% endcomponent %}
		""").render(Context({})),
	),

	TabEntry(
		header="Tab 2",
		content="Hello this is tab 2",
	),
]

Tabs.render(
	kwargs={
		"tabs": tabs,
	}
)

This new approach has multiple advantages:

• The templating (AKA where you position the components) and all relevant info like HTML attributes can be colocated inside the HTML file.
• The nested HTML (like the content of Tab 1) can access the original Context.
  • If I defined the tabs inside Python, I would need to wire the original Context to the tabs. Since django-components does NOT expose the Context instance, one would have to override the render methods or otherwise intercept. With the new approach, we get the access to the Context for free!
• Personally I find it easier readable.

For anyone curious, the source code is below:

tabs.py

from typing import NamedTuple

from django.utils.safestring import mark_safe
from django_components import component, types as t

from app_home.helpers.components import Component


class TabEntry(NamedTuple):
    header: str
    content: str
    disabled: bool = False


@component.register("_tabs")
class _TabsImpl(Component):
    template_name = "tabs.html"

    class Media:
        js = "tabs.js"

    def setup_context(
        self,
        *_args,
        tabs: list[TabEntry],
        # Unique name to identify this tabs instance, so we can open/close the tabs
        # based on the query params.
        name: str | None = None,
        attrs: dict | None = None,
        header_attrs: dict | None = None,
        content_attrs: dict | None = None,
    ):
        return {
            "attrs": attrs,
            "tabs": tabs,
            "header_attrs": header_attrs,
            "content_attrs": content_attrs,
            "tabs_data": {"name": name},
        }


# This is an "API" component, meaning that it's designed to process
# user input provided as nested components. But after the input is
# processed, it delegates to an internal "implementation" component
# that actually renders the content.
@component.register("tabs")
class Tabs(Component):
    template: t.django_html = """
        {% provide "_tab" tabs=tabs enabled=True %}
            {% slot "content" default %}{% endslot %}
        {% endprovide %}
    """

    def setup_context(
        self,
        *_args,
        # Unique name to identify this tabs instance, so we can open/close the tabs
        # based on the query params.
        name: str | None = None,
        attrs: dict | None = None,
        header_attrs: dict | None = None,
        content_attrs: dict | None = None,
    ):
        return {
            "tabs": [],
            "name": name,
            "attrs": attrs,
            "header_attrs": header_attrs,
            "content_attrs": content_attrs,
            "tabs_data": {"name": name},
        }

    def on_render_postprocess(self, context, template, content):
        # By the time we get here, all child TabItem components should have been
        # rendered, and they should've populated the tabs list.
        tabs: list[TabEntry] = context["tabs"]
        return _TabsImpl.render(
            kwargs={
                "tabs": tabs,
                "name": context["name"],
                "attrs": context["attrs"],
                "header_attrs": context["header_attrs"],
                "content_attrs": context["content_attrs"],
            },
        )


# Use this component to define individual tabs inside the default slot
# inside the `tab` component.
@component.register("tab_item")
class TabItemComp(Component):
    template: t.django_html = """
        {% provide "_tab" tabs=empty_tabs enabled=False %}
            {% slot "content" default %}{% endslot %}
        {% endprovide %}
    """

    def setup_context(
        self,
        *_args,
        header: str,
        disabled: bool = False,
    ):
        # Access the list of tabs registered for parent Tabs component
        # This raises if we're not nested inside the Tabs component.
        tab_ctx = self.inject("_tab")

        # We accessed the _tab context, but we're inside ANOTHER tab_item
        if not tab_ctx.enabled:
            raise RuntimeError(
                f"Component '{self.name}' was called with no parent Tabs component. "
                f"Either wrap '{self.name}' in Tabs component, or check if the component "
                f"is not a descendant of another instance of '{self.name}'"
            )

        return {
            "empty_tabs": [],
            "parent_tabs": tab_ctx.tabs,
            "header": header,
            "disabled": disabled,
        }

    def on_render_after(self, context, template, content):
        parent_tabs: list[dict] = context["parent_tabs"]
        parent_tabs.append({
            "header": context["header"],
            "disabled": context["disabled"],
            "content": mark_safe(content.strip()),
        })

tabs.html

<div
  x-data="tabs"
  data-init="{{ tabs_data|json|escape }}"
  {% html_attrs attrs %}
>
  <ul class="flex border-b">
    {% for tab in tabs %}
      {% if not tab.disabled %}
      <li
        @click="setOpenTab( {{ forloop.counter }} )"
        :class="{
          'border-b-2 border-blue-700': openTab === {{ forloop.counter }}
        }"
        {% html_attrs header_attrs %}
      >
        <a
          href="#"
          :class="openTab === {{ forloop.counter }} ? activeClasses : inactiveClasses"
          class="bg-white inline-block py-2 px-4 font-semibold"
        >
          {{ tab.header }}
        </a>
      </li>
      {% else %}
      <li class="mr-1">
        <p class="text-gray-300 bg-white inline-block py-2 px-4 font-semibold">
          {{ tab.header }}
        </p>
      </li>
      {% endif %}
    {% endfor %}
  </ul>
  <div class="w-full h-full relative overflow-y-scroll" x-ref="container">
    <article class="px-4 py-5 sm:p-6 absolute w-full">
      {% for tab in tabs %}
      <div
        x-show="openTab === {{ forloop.counter }}"
        {% html_attrs content_attrs %}
      >
        {{ tab.content }}
      </div>
      {% endfor %}
    </article>
  </div>
</div>

The example above uses:

• Custom subclass of django-component's Component class.
  • This subclass has hooks for before/after rendering, and for post-processing the rendered template. I plan to make an MR to add the hooks.
• The provide/inject feature
• html_attrs and the prop:key=val syntax to allow users to provide arbitrary HTML attributes.
• AlpineJS for JS (omitted)
• Tailwind CSS

How it works is that:

1. The tabs component expects only tab_item components in it's slot.
2. At the start of rendering, tabs component "provides" an empty array
3. For each tab_item component that is rendered inside the tabs slot, tab_item "injects" the array from the parent tabs component. And at the end of rendering of tab_item, using one of the hooks, tab_item adds its own rendered content into the tabs array, to which it still holds a reference.
4. Once the tabs's slot is rendered, we use the postprocess hook. At this point, the "provided" array is populated with the rendered content of tab_items.
5. We pass the pre-rendered tabs to _TabsImpl. At this point, it's the same biz as before - we pass data as props, and component renders it.

[EmilStenstrom]

Hi! Can I ask some questions about the code in tabs.py? The intent is trying to figure out if there's more we can do to simplify writing components like this:

• How come you use setup_context instead of get_context_data?
• A large part of all the code is just the setup_context definitions, could we do something smarter there?
• The difference between a Tab and TabImpl seems excessive, wouldn't it be easier to combine them?
• What's the difference between on_render_postprocess and on_render_after?

[JuroOravec]

Sure!

How come you use setup_context instead of get_context_data?

setup_context is just renamed get_context_data, it's a leftover of the fact that in my fork I was also playing with the idea of using a function signature closer to Vue / React, where the first arg is an object of props.

---

A large part of all the code is just the setup_context definitions, could we do something smarter there?

Hm, so theoretically some of it could be now simplified thanks to #629 - instead of defining full function signature for each setup_context , one could now re-use the definitions for args / kwargs via the types. So then setup_context's signature could be simply setup_context(self, *args, **kwargs). So e.g.:

class TabsKwargs(TypedDict):
	...

@component.register("tabs")
class Tabs(Component[TabsArgs, TabsKwargs, TabsData, TabsSlots]):
	template = ...

    def setup_context(self, *args, **kwargs):
		name = kwargs.get("name", None)
        return {
            "tabs": [],
            "name": name,
            "attrs": kwargs.get("attrs", None),
            "header_attrs": kwargs.get("header_attrs", None),
            "content_attrs": kwargs.get("content_attrs", None),
            "tabs_data": {"name": name},
        }

Then, a lot of repetition comes from passing the same value from the input of setup_context to the context, aka all those

return {
    "attrs": kwargs.get("attrs", None),
    "header_attrs": kwargs.get("header_attrs", None),
    "content_attrs": kwargs.get("content_attrs", None),
}

Personally I think it's good to have explicitly defined data. One thing that could help, that I'm also cooking up, and which is inspired by django-viewcomponent, is that they made the component instance accessible via self context var ({{ self }}).

In combination with the fact that component inputs are accessible via self.input.args, self.input.kwargs, self.input.slots, it means that one could skip returning the inputs un-modified in get_context_data, one could instead access the original unmodified inputs inside the template like so:

name: {{ self.input.kwargs.name }}

So this would be practically the same as the template $props and $slots attributes in Vue.

With these combined, we could shorten the setup_context definition to

class TabsKwargs(TypedDict):
	...

@component.register("tabs")
class Tabs(Component[TabsArgs, TabsKwargs, TabsData, TabsSlots]):
	template = ...

    def setup_context(self, *args, **kwargs):
		name = kwargs.get("name", None)
        return {
            "tabs": [],
            "name": name,
            "tabs_data": {"name": name},
        }

---

The difference between a Tab and TabImpl seems excessive, wouldn't it be easier to combine them?

Possibly could be merged, though then I would need to take different approach. Because for this to work, I need to render 2 templates: First renders the slot fill with TabItems, the second one is the actual implementation.

And the approach I took was to let django_components do its biz and render the template, and then use the outputs of that to render another template.

Theoretically, I could have done something like this, so we'd render the short template snippet inside on_before_render which would indirectly make the TabItems inject and populate the tabs provided list.

@component.register("tabs")
class Tabs(Component):
    template_name: "tabs.html"

    def setup_context() ...

    def on_before_render(self, context, template, content):
		# Render TabItems in the given slot, which populates context["tabs"]
		Template("""
			{% provide "_tab" tabs=empty_tabs enabled=False %}
			    {% slot "content" default %}{% endslot %}
			{% endprovide %}
		""").render(context)

But for this to work, I think we'd also need to put the content slot inside tabs.html, otherwise django_components would complain that it received a slot it did not declare. A workaround for that could be to include inside tabs.html something like this:

{% if False %}
	{% slot "content" default / %}
{% endif %}

So overall, I could have merged Tabs and TabsImpl, but it wold be more hacky it feels.

---

What's the difference between on_render_postprocess and on_render_after?

I dropped on_render_postprocess. But initially I included both, with a reasoning that:

• on_render_postprocess would be explicitly used for modifying the rendered content
• on_render_after would be used for side-effects that don't need to modify the rendered content.

But in the end, I decided to merge them into on_render_after, with the logic that IF on_render_after returns something, then it overwrites the rendered content.

[mscheper]

So is this possible, out of the box, with the current release of django_components (0.139.1)? Is there a plug-in for the provides tag? Or does it require more home-grown code? Tabs like these are exactly what I'm trying to implement right now, and what I've come up with so far is much messier than I think it ought to be.

[mscheper]

Too easy—I just had to change the Media class so it includes Alpine as well:

@register("_tabs")
class _TabsImpl(Component):
    template_name = "tabs.html"

    class Media:
        js = [
            "tabs.js",
            "https://unpkg.com/[email protected]/dist/cdn.min.js",  # AlpineJS
        ]

Now, did you post your CSS somewhere too, or is it all just Tailwind?

Thanks!

[JuroOravec]

Looking at the HTML, should be all Tailwind.

Tailwind was installed with django-tailwind. But I think for the sake of the demo you can also also use the CDN if you don't want to set up Tailwind just for this

I just noticed in that the HTML template there's also a variable theme. You can ignore / remove this, that's again just project-specific thing.

Btw do post your code here once you've got it working. Would be amazing to be able to show an example that other could just copy-paste.

[mscheper]

Thanks. So my next question about your code: What's dliver, in the setOpenTab JS code posted above?

I do plan to post what I come up with, and it seems something worth submitting as a pull request to some library, since I remain surprised that tabs aren't a built-in feature of Django-Components. But I suppose part of the challenge is that not everyone uses the same front-end tech, especially as far as look and feel go.

I, for example, haven't been convinced to try Tailwind yet. Many dozens of wasted hours fighting with Bootstrap convinced me it's best to just write CSS by hand, and since I value accessibility, the CSS I'm writing will render according to WAI-ARIA attributes. So I'm basically working on merging this with your code, but having it still support the tab query parameters that your code features. I suppose that dliver has something to do with that? (But this also means the theme variable you mentioned is already on the cutting room floor—thanks anyhow).

As a result, adding tabs to my site is taking exponentially more time than I expected. But it's also helping me understand Django-Components and Alpine more, so I don't think it's time wasted. Perhaps the majority of other devs have gone down the Tailwind and Vue path instead, although since those don't seem to come with tabs in the box either, I don't think, for me, that'd've been worth the learning curve.

[EmilStenstrom]

@mscheper The core idea behind django-components is to provide a framework for working with components. But the actual components is something you have to write yourself. Just like you say, the choice of CSS and JS tools is left as an exercise for the reader :) I think there's space for a third party to write a set of cohesive components on top of this library, but we don't currently know of somehow who've done that.

[JuroOravec]

Thanks. So my next question about your code: What's dliver, in the setOpenTab JS code posted above?

@mscheper Ooops, dliver is also project-specific logic, I've just removed it from that example above.

The thing is that my actual implementation also has a two-way integration with the URL, so on page load when the URL contains a specific query param / hash, then the JS logic detects that, and updates the AlpineJS state of the Tabs component, which opens the correct tab. And when user opens a different tab, this pushes the state to the URL.

And that logic was defined on that dliver object.

I do plan to post what I come up with, and it seems something worth submitting as a pull request to some library, since I remain surprised that tabs aren't a built-in feature of Django-Components. But I suppose part of the challenge is that not everyone uses the same front-end tech, especially as far as look and feel go.

Yeah as @EmilStenstrom said, django-components is the underlying library, same as Vue or React are, and specific UI components are outside of the scope.

I personally want to port Vuetify onto django-components + AlpineJS, to have battle-tested high quality components without reinventing the wheel. Buuut what I thought would be a 3 month side-quest turned out to be small PhD project 😄

but having it still support the tab query parameters that your code features. I suppose that dliver has something to do with that?

Sorry didn't realize you wanted the tabs to be integrated with the query params. In that case we can put the dliver object back. 😅

You can use the code below:

• tabs.js - The original tabs.js, without any deletions, so it now includes the integration with query params
• queryManager.js - Logic for 2-way integration with query params
• base.js - This is where the dliver object is defined. There I also the initial state of queryManager.

I think you will then also need to load these in the correct order:

@register("_tabs")
class _TabsImpl(Component):
    template_name = "tabs.html"

    class Media:
        js = [
            "queryManager.js",
            "base.js",
            "tabs.js",
            "https://unpkg.com/[email protected]/dist/cdn.min.js",  # AlpineJS
        ]

queryManager.js

/**
 * Callback when a URL's query param changes.
 *
 * @callback OnParamChangeCallback
 * @param {string | null} newValue - New value of the query param.
 * @param {string | null} oldValue - Old value of the query param.
 */

/**
 * Function that can be called once to remove the registered callback.
 *
 * @callback UnregisterFn
 */

/**
 * Callback for modifying URL.
 *
 * @callback OnUrlModifyCallback
 * @param {URL} currUrl - Current URL.
 * @returns {URL | string} New URL.
 */

/**
 * Singular interface for manipulating URL search/query parameters
 * and reacting to changes.
 *
 * See https://developer.mozilla.org/en-US/docs/Web/API/Location/search
 */
const createQueryManager = () => {
  /**
   * @type {Record<string, OnParamChangeCallback[]>}
   */
  const callbacks = {};

  /**
   * Store previous values of query params, so we can provide both new and old
   * values to the callbacks.
   *
   * NOTE: Use `setParamValue` instead of setting values directly.
   *
   * @type {Record<string, string | null>}
   */
  const previousParamValues = {};

  /**
   * @param {string} key
   * @param {string | null} newValue
   */
  const setParamValue = (key, newValue) => {
    const oldValue =
      previousParamValues[key] === undefined ? null : previousParamValues[key];

    previousParamValues[key] = newValue;

    const paramCallbacks = callbacks[key] || [];

    paramCallbacks.forEach((cb) => cb(newValue, oldValue));
  };

  /**
   * Register a listener that will be triggered when a value changes for the query param
   * of given name.
   *
   * Returns a function that can be called once to remove the registered callback.
   *
   * @param {string} paramName
   * @param {OnParamChangeCallback} callback
   * @returns {UnregisterFn}
   */
  const registerParam = (paramName, callback) => {
    if (callbacks[paramName] == undefined) {
      callbacks[paramName] = [];
    }

    callbacks[paramName].push(callback);

    // Run the callback once if the query param already has some value
    if (previousParamValues[paramName] != null) {
      callback(previousParamValues[paramName], null);
    }

    // Return a function that can be called once to remove the registered callback
    let unregisterCalled = false;
    const unregister = () => {
      if (unregisterCalled) return;
      unregisterCalled = true;

      unregisterParam(paramName, callback);
    };

    return unregister;
  };

  /**
   * Unregister a callback that was previously registered with `registerParam`
   * for the query param of given name.
   *
   * @param {string} paramName
   * @param {OnParamChangeCallback} callback
   */
  const unregisterParam = (paramName, callback) => {
    // Nothing to do
    if (callbacks[paramName] == undefined) return;

    // Remove one instance of callback from the array to simulate similar behavior
    // as browser's addEventListener/removeEventListener.
    // See https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/addEventListener
    const indexToRemove = callbacks[paramName].indexOf(callback);
    if (indexToRemove !== -1) {
      callbacks[paramName].splice(indexToRemove, 1);
    }
  };

  /**
   * Shared logic for modifying the page's URL in-place (without reload).
   *
   * @param {OnUrlModifyCallback} mapFn
   */
  const modifyUrl = (mapFn) => {
    // Prepare current URL
    const currUrl = new URL(globalThis.location.href);

    // Let the user of this function decide how to transform the URL
    let updatedUrl = mapFn(currUrl);

    // Update browser URL without reloading the page
    // See https://developer.mozilla.org/en-US/docs/Web/API/History/pushState
    // And https://stackoverflow.com/a/3354511/9788634
    globalThis.history.replaceState(null, "", updatedUrl.toString());
  };

  /**
   * Set query parameters to the URL.
   *
   * If the URL already contains query params of the same name, these will be overwritten.
   *
   * @param {Record<string, string>} params
   */
  const setParams = (params) => {
    modifyUrl((currUrl) => {
      Object.entries(params).forEach(([key, val]) => {
        currUrl.searchParams.set(key, val);
      });
      return currUrl.href;
    });

    // Trigger callbacks for all params that were set.
    Object.entries(params).forEach(([key, val]) => setParamValue(key, val));
  };

  /** Clear all query parameters from the URL. */
  const clearParams = () => {
    modifyUrl((currUrl) => {
      currUrl.search = "";
      return currUrl.href;
    });

    // Trigger callbacks for all params that were unset.
    Object.entries(previousParamValues)
      .filter(([key, val]) => val !== null)
      .forEach(([key, val]) => setParamValue(key, val));
  };

  /** Load query params from the current page URL, triggering any registered callbacks. */
  const load = () => {
    const currUrl = new URL(globalThis.location.href);
    currUrl.searchParams.forEach((value, key) => setParamValue(key, value));
  };

  return {
    setParams,
    clearParams,
    registerParam,
    unregisterParam,
    load,
  };
};

base.js

/** Global JS state / methods */
const dliver = {
  // NOTE: queryManager.js MUST be loaded before this script!
  query: createQueryManager(),
};

// Set query params state from the URL on page load.
dliver.query.load();

tabs.js

document.addEventListener("alpine:init", () => {
  Alpine.data("tabs", () => ({
    // Variables
    openTab: 1,
    name: null,

    // Computed
    get tabQueryName() {
      return `tabs-${this.name}`;
    },

    // Methods
    init() {
      // If we provided the `name` argument to the "tabs" component, then
      // we register a listener for the query param `tabs-{name}`.
      // The value of this query param is the current active tab (index).
      //
      // When user changes the currently-open tab, we push that info to the URL
      // by updating the `tabs-{name}` query param.
      //
      // And when we navigate to a URL that already had `tabs-{name}` query param
      // set, we load that tab.
      if (this.$el.dataset['init']) {
        const { name } = JSON.parse(this.$el.dataset['init']);

        if (name) {
          this.name = name
          dliver.query.registerParam(
            this.tabQueryName,
            (newVal, oldVal) => this.onTabQueryParamChange(newVal, oldVal),
          );
        }
      }

      // Sometimes, the scrollable tab content area is scrolled to the bottom
      // when the page loads. So we ensure here that the we scroll to the top if not already
      // Also see https://developer.mozilla.org/en-US/docs/Web/API/Element/scrollTop
      const containerEl = this.$refs.container;
      if (containerEl.scrollTop) {
        this.$refs.container.scrollTop = 0;
      }
    },

    /**
     * Set the current open tab and push the info to query params.
     *
     * @param {number} tabIndex
     */
    setOpenTab(tabIndex) {
      this.openTab = tabIndex;

      if (this.name) {
        dliver.query.setParams({ [this.tabQueryName]: tabIndex });
      }
    },

    /**
     * Handle tab change from URL
     *
     * @param {*} newValue
     * @param {*} oldValue
     */
    onTabQueryParamChange(newValue, oldValue) {
      if (newValue == null) return;

      const newValNum = typeof newValue === "number" ? newValue : Number.parseInt(newValue);
      if (newValNum === this.openTab) return;

      this.setOpenTab(newValNum);
    },
  }));
});

[mscheper]

Getting this working turned into a nice Friday project.

I realised that preserving the selected tab between requests would require modifying numerous links on the page, and thus be too customised to include here. I think I'll probably end up adding some Alpine smarts that looks at the anchor in the request, and makes the appropriate tab visible according to that. So the code I'm posting here has none of those features; just tabs (but ones that should play nicely with assistive tech). And as such, there's no separate Javascript file; just Alpine. And the code includes Alpine by itself, and loads component_tags; I think the only thing that devs should really need to configure for this to work is installing Django-Components.

The styling is plain CSS, not based on HTML classes at all, rather WAI-ARIA attributes. To change the colours of tabs and things, I suggest adding selectors like document [role="tab"] to a sitewide CSS file, so they're more specific and should therefore override what's in tabs.css. Or maybe there's a better way with Tailwind; I don't know.

I've changed various names in your code so they're consistent with WAI-ARIA, so templates should now put Tab components inside of Tablist components. (Only one capital in Tablist, because 'tablist' is one word in WAI-ARIA-speak—event names like 'mouseover' have become pretty much accepted as single words, so I'm running with that. I get fussy about names, but it seems to make my code easier for at least some other devs to understand.) Similarly, the tab content now goes in a 'panel'.

Example use in a template:

{% component "Tablist"
  id="optional-tablist-id"
  name="Bonza tablist"
  container_attrs:class="optional-container-attrs"
  tablist_attrs:class="optional-tablist-attrs"
  tab_attrs:class="optional-tab-attrs"
  tabpanel_attrs:class="optional-panel-attrs"
%}
  {% component "Tab" id="optional-tab-id" header="I'm a tab!" %}
    {% lorem %}
  {% endcomponent %}
  {% component "Tab" header="I'm also a tab!" %}
    <p>{% lorem %}</p>
    <p>{% lorem %}</p>
  {% endcomponent %}
  {% component "Tab" header="I am a gorilla!" %}
    <p>{% lorem %}</p>
    <p>I wonder if anyone got the Monty Python reference. 🤔</p>
  {% endcomponent %}
{% endcomponent %}

The only mandatory arguments are the the Tab headers. The tablist's name does get used for the ARIA-label, though, so it's a good idea to give it a meaningful name, which will then also get used to create default ids for the tablist and tabs. But the name can be omitted, in which case it'll just be named 'Tabs'. This means that if there's more than one set of tabs on the page, they'll have the same ID, unless they're given different names or explicitly different IDs—so again, it's a good idea to give names. 🙂

And here's the code:

components/tabs/tabs.py

"""
Alpine-based tab components: Tablist and Tab.

Based on https://github.com/django-components/django-components/discussions/540
"""

from typing import NamedTuple

from django.conf import settings
from django.utils.safestring import mark_safe
from django.utils.text import slugify
from django_components import Component, register, types as t


class TabDatum(NamedTuple):
    """Datum for an individual tab."""

    id: str
    header: str
    content: str
    disabled: bool = False


@register("_tabset")
class _TablistImpl(Component):
    """Delegated Tablist component.

    Refer to `Tablist` API below.
    """

    template_name = "tabs.html"

    class Media:
        js = (settings.ALPINE_JS_INCLUDE,)
        css = "tabs.css"

    def get_context_data(
        self,
        /,
        *,
        tab_data: list[TabDatum],
        id: str | None = None,
        name: str | None = None,
        container_attrs: dict | None = None,
        tablist_attrs: dict | None = None,
        tab_attrs: dict | None = None,
        tabpanel_attrs: dict | None = None,
    ):
        return {
            "id": id,
            "name": name,
            "container_attrs": container_attrs,
            "tablist_attrs": tablist_attrs,
            "tab_attrs": tab_attrs,
            "tabpanel_attrs": tabpanel_attrs,
            "tab_data": tab_data,
            "selected_tab": tab_data[0]["id"],
        }


@register("Tablist")
class Tablist(Component):
    """Tablist role component comprised of nested tab components.

    After the input is processed, this component delegates to an internal implementation
    component that renders the content.

    `name` identifies the tablist and is used as a WAI-ARIA label

    `id`, by default, is a sligified `name`, we could be used to preselect a tab based
    on query parameters (TODO)
    """

    template: t.django_html = """
        {% load component_tags %}
        {% provide "_tab" id=id tab_data=tab_data enabled=True %}
            {% slot "content" default / %}
        {% endprovide %}
    """

    def get_context_data(
        self,
        /,
        *,
        id: str | None = None,
        name: str | None = "Tabs",
        container_attrs: dict | None = None,
        tablist_attrs: dict | None = None,
        tab_attrs: dict | None = None,
        tabpanel_attrs: dict | None = None,
    ):
        id = id or slugify(name)
        return {
            "id": id,
            "name": name,
            "container_attrs": container_attrs,
            "tablist_attrs": tablist_attrs,
            "tab_attrs": tab_attrs,
            "tabpanel_attrs": tabpanel_attrs,
            "tab_data": [],
            "selected_tab": "",
        }

    def on_render_after(self, context, template, rendered) -> str:
        """Render the tab set.

        By the time we get here, all child Tab components should have been rendered,
        and they should've populated the tablist.
        """
        tab_data: list[TabDatum] = context["tab_data"]
        return _TablistImpl.render(
            kwargs={
                "id": context["id"],
                "name": context["name"],
                "container_attrs": context["container_attrs"],
                "tablist_attrs": context["tablist_attrs"],
                "tab_attrs": context["tab_attrs"],
                "tabpanel_attrs": context["tabpanel_attrs"],
                "tab_data": tab_data,
            },
            render_dependencies=False,
        )


@register("Tab")
class Tab(Component):
    """Individual tab, inside the default slot inside the `Tablist` component."""

    template: t.django_html = """
        {% load component_tags %}
        {% provide "_tab" id=id tab_data=empty_tab_data enabled=False %}
            {% slot "content" default / %}
        {% endprovide %}
    """

    def get_context_data(
        self,
        /,
        *,
        header: str,
        disabled: bool = False,
        id: str | None = None,
    ):
        """Access the tab data registered for the parent Tablist component.

        This raises if we're not nested inside a Tablist component.
        """
        tab_ctx = self.inject("_tab")

        # We accessed the _tab context, but we're inside ANOTHER Tab
        if not tab_ctx.enabled:
            raise RuntimeError(
                f"Component '{self.name}' was called with no parent Tablist component. "
                f"Either wrap '{self.name}' in Tablist component, or check if the "
                f"component is not a descendant of another instance of '{self.name}'"
            )

        slugs = (slugify(tab_ctx.id), slugify(header))
        return {
            "empty_tab_data": [],
            "parent_tabs": tab_ctx.tab_data,
            "id": id or "%s_%s_tab" % slugs,
            "tabpanel_id": f"{id}_content" if id else "%s_%s_content" % slugs,
            "header": header,
            "disabled": disabled,
        }

    def on_render_after(self, context, template, content) -> None:
        parent_tabs: list[dict] = context["parent_tabs"]
        parent_tabs.append(
            {
                "id": context["id"],
                "tabpanel_id": context["tabpanel_id"],
                "header": context["header"],
                "disabled": context["disabled"],
                "content": mark_safe(content.strip()),
            }
        )

components/tabs/tabs.html

{% load component_tags %components/tabs/tabs.py}
<div
  x-data="{ selectedTab: '{{ selected_tab }}' }"
  {% html_attrs
    container_attrs
    id=id
  %}
>
  <div
    {% html_attrs
      tablist_attrs
      role="tablist"
      aria-label=name
    %}>
    {% for tab_datum in tab_data %}
      <button
        :aria-selected="selectedTab === '{{ tab_datum.id }}'"
        @click="selectedTab = '{{ tab_datum.id }}'"
        {% html_attrs
          tab_attrs
          id=tab_datum.id
          role="tab"
          aria-controls=tab_datum.id
          disabled=tab_datum.disabled
        %}>
        {{ tab_datum.header }}
      </button>
    {% endfor %}
  </div>
  {% for tab_datum in tab_data %}
    <article
      :hidden="selectedTab != '{{ tab_datum.id }}'"
      {% html_attrs
        tabpanel_attrs
        hidden=forloop.first|not
        role="tabpanel"
        id=tab_datum.tabpanel_id
        aria-labelledby=tab_datum.id
      %}>
      {{ tab_datum.content }}
    </article>
  {% endfor %}
</div>

components/tabs/tabs.css

/* based on https://codepen.io/brettsmason/pen/zYGEgZP */

[role="tablist"] {
  margin: 0 0 -0.1em;
  overflow: visible;
}

[role="tab"] {
  position: relative;
  margin: 0;
  padding: 0.3em 0.5em 0.4em;
  border: 1px solid hsl(219, 1%, 72%);
  border-radius: 0.2em 0.2em 0 0;
  box-shadow: 0 0 0.2em hsl(219, 1%, 72%);
  overflow: visible;
  font-family: inherit;
  font-size: inherit;
  background: hsl(220, 20%, 94%);
}

[role="tab"]:hover::before,
[role="tab"]:focus::before,
[role="tab"][aria-selected="true"]::before {
  position: absolute;
  bottom: 100%;
  right: -1px;
  left: -1px;
  border-radius: 0.2em 0.2em 0 0;
  border-top: 3px solid LinkText;
  content: '';
}

[role="tab"][aria-selected="true"] {
  border-radius: 0;
  background: hsl(220, 43%, 99%);
  outline: 0;
}

[role="tab"][aria-selected="true"]:not(:focus):not(:hover)::before {
  border-top: 5px solid SelectedItem;
}

[role="tab"][aria-selected="true"]::after {
  position: absolute;
  z-index: 3;
  bottom: -1px;
  right: 0;
  left: 0;
  height: 0.3em;
  background: hsl(220, 43%, 99%);
  box-shadow: none;
  content: '';
}

[role="tab"]:hover,
[role="tab"]:focus,
[role="tab"]:active {
  outline: 0;
  border-radius: 0;
  color: inherit;
}

[role="tab"]:hover::before,
[role="tab"]:focus::before {
  border-color: LinkText;
}

[role="tabpanel"] {
  position: relative;
  z-index: 2;
  padding: 0.5em 0.5em 0.7em;
  border: 1px solid hsl(219, 1%, 72%);
  border-radius: 0 0.2em 0.2em 0.2em;
  box-shadow: 0 0 0.2em hsl(219, 1%, 72%);
  background: hsl(220, 43%, 99%);
}

[role="tabpanel"]:focus {
  border-color: LinkText;
  box-shadow: 0 0 0.2em LinkText;
  outline: 0;
}

[role="tabpanel"]:focus::after {
  position: absolute;
  bottom: 0;
  right: -1px;
  left: -1px;
  border-bottom: 3px solid LinkText;
  border-radius: 0 0 0.2em 0.2em;
  content: '';
}

[role="tabpanel"] p {
  margin: 0;
}

[role="tabpanel"] * + p {
  margin-top: 1em;
}

I'm definitely open to hearing about more improvements. I meant to make functions like get_context_data build their return values based mostly on locals(), and make other similar DRY improvements, but it's time for me to get on with it and actually use these. But if I come up with a particularly elegant way to update query params or anchors according to the selected tab, I'll post about that too.