Release notes¤

Version 0.97 - Fixed template caching. You can now also manually create cached templates with cached_template() - The previously undocumented get_template was made private. - In it's place, there's a new get_template, which supersedes get_template_string (will be removed in v1). The new get_template is the same as get_template_string, except it allows to return either a string or a Template instance. - You now must use only one of template, get_template, template_name, or get_template_name.

Version 0.96 - Run-time type validation for Python 3.11+ - If the Component class is typed, e.g. Component[Args, Kwargs, ...], the args, kwargs, slots, and data are validated against the given types. (See Runtime input validation with types) - Render hooks - Set on_render_before and on_render_after methods on Component to intercept or modify the template or context before rendering, or the rendered result afterwards. (See Component hooks) - component_vars.is_filled context variable can be accessed from within on_render_before and on_render_after hooks as self.is_filled.my_slot

Version 0.95 - Added support for dynamic components, where the component name is passed as a variable. (See Dynamic components) - Changed Component.input to raise RuntimeError if accessed outside of render context. Previously it returned None if unset.

Version 0.94 - django_components now automatically configures Django to support multi-line tags. (See Multi-line tags) - New setting reload_on_template_change. Set this to True to reload the dev server on changes to component template files. (See Reload dev server on component file changes)

Version 0.93 - Spread operator ...dict inside template tags. (See Spread operator) - Use template tags inside string literals in component inputs. (See Use template tags inside component inputs) - Dynamic slots, fills and provides - The name argument for these can now be a variable, a template expression, or via spread operator - Component library authors can now configure CONTEXT_BEHAVIOR and TAG_FORMATTER settings independently from user settings.

🚨📢 Version 0.92 - BREAKING CHANGE: Component class is no longer a subclass of View. To configure the View class, set the Component.View nested class. HTTP methods like get or post can still be defined directly on Component class, and Component.as_view() internally calls Component.View.as_view(). (See Modifying the View class)

• The inputs (args, kwargs, slots, context, ...) that you pass to Component.render() can be accessed from within get_context_data, get_template and get_template_name via self.input. (See Accessing data passed to the component)

• Typing: Component class supports generics that specify types for Component.render (See Adding type hints with Generics)

Version 0.90 - All tags (component, slot, fill, ...) now support "self-closing" or "inline" form, where you can omit the closing tag:

{# Before #}
{% component "button" %}{% endcomponent %}
{# After #}
{% component "button" / %}

{% component "button" attrs:class="hidden" %}

The default is `django_components.component_formatter`:
```django
{% component "button" href="..." disabled %}
    Click me!
{% endcomponent %}
```

While `django_components.shorthand_component_formatter` allows you to write components like so:

```django
{% button href="..." disabled %}
    Click me!
{% endbutton %}

🚨📢 Version 0.85 Autodiscovery module resolution changed. Following undocumented behavior was removed:

• Previously, autodiscovery also imported any [app]/components.py files, and used SETTINGS_MODULE to search for component dirs.
• To migrate from:
  • [app]/components.py - Define each module in COMPONENTS.libraries setting, or import each module inside the AppConfig.ready() hook in respective apps.py files.
  • SETTINGS_MODULE - Define component dirs using STATICFILES_DIRS
• Previously, autodiscovery handled relative files in STATICFILES_DIRS. To align with Django, STATICFILES_DIRS now must be full paths (Django docs).

🚨📢 Version 0.81 Aligned the render_to_response method with the (now public) render method of Component class. Moreover, slots passed to these can now be rendered also as functions.

• BREAKING CHANGE: The order of arguments to render_to_response has changed.

Version 0.80 introduces dependency injection with the {% provide %} tag and inject() method.

🚨📢 Version 0.79

• BREAKING CHANGE: Default value for the COMPONENTS.context_behavior setting was changes from "isolated" to "django". If you did not set this value explicitly before, this may be a breaking change. See the rationale for change here.

🚨📢 Version 0.77 CHANGED the syntax for accessing default slot content.

• Previously, the syntax was {% fill "my_slot" as "alias" %} and {{ alias.default }}.
• Now, the syntax is {% fill "my_slot" default="alias" %} and {{ alias }}.

Version 0.74 introduces html_attrs tag and prefix:key=val construct for passing dicts to components.

🚨📢 Version 0.70

• {% if_filled "my_slot" %} tags were replaced with {{ component_vars.is_filled.my_slot }} variables.
• Simplified settings - slot_context_behavior and context_behavior were merged. See the documentation for more details.

Version 0.67 CHANGED the default way how context variables are resolved in slots. See the documentation for more details.

🚨📢 Version 0.5 CHANGES THE SYNTAX for components. component_block is now component, and component blocks need an ending endcomponent tag. The new python manage.py upgradecomponent command can be used to upgrade a directory (use --path argument to point to each dir) of templates that use components to the new syntax automatically.

This change is done to simplify the API in anticipation of a 1.0 release of django_components. After 1.0 we intend to be stricter with big changes like this in point releases.

Version 0.34 adds components as views, which allows you to handle requests and render responses from within a component. See the documentation for more details.

Version 0.28 introduces 'implicit' slot filling and the default option for slot tags.

Version 0.27 adds a second installable app: django_components.safer_staticfiles. It provides the same behavior as django.contrib.staticfiles but with extra security guarantees (more info below in Security Notes).

Version 0.26 changes the syntax for {% slot %} tags. From now on, we separate defining a slot ({% slot %}) from filling a slot with content ({% fill %}). This means you will likely need to change a lot of slot tags to fill. We understand this is annoying, but it's the only way we can get support for nested slots that fill in other slots, which is a very nice featuPpre to have access to. Hoping that this will feel worth it!

Version 0.22 starts autoimporting all files inside components subdirectores, to simplify setup. An existing project might start to get AlreadyRegistered-errors because of this. To solve this, either remove your custom loading of components, or set "autodiscover": False in settings.COMPONENTS.

Version 0.17 renames Component.context and Component.template to get_context_data and get_template_name. The old methods still work, but emit a deprecation warning. This change was done to sync naming with Django's class based views, and make using django-components more familiar to Django users. Component.context and Component.template will be removed when version 1.0 is released.

Static files

Components can be organized however you prefer. That said, our prefered way is to keep the files of a component close together by bundling them in the same directory. This means that files containing backend logic, such as Python modules and HTML templates, live in the same directory as static files, e.g. JS and CSS.

If your are using django.contrib.staticfiles to collect static files, no distinction is made between the different kinds of files. As a result, your Python code and templates may inadvertently become available on your static file server. You probably don't want this, as parts of your backend logic will be exposed, posing a potential security vulnerability.

As of v0.27, django-components ships with an additional installable app django_components.safer_staticfiles. It is a drop-in replacement for django.contrib.staticfiles. Its behavior is 100% identical except it ignores .py and .html files, meaning these will not end up on your static files server. To use it, add it to INSTALLED_APPS and remove django.contrib.staticfiles.

INSTALLED_APPS = [
    # 'django.contrib.staticfiles',   # <-- REMOVE
    'django_components',
    'django_components.safer_staticfiles'  # <-- ADD
]

If you are on an older version of django-components, your alternatives are a) passing --ignore <pattern> options to the collecstatic CLI command, or b) defining a subclass of StaticFilesConfig. Both routes are described in the official docs of the staticfiles app.

Note that safer_staticfiles excludes the .py and .html files for collectstatic command:

python manage.py collectstatic

but it is ignored on the development server:

python manage.py runserver

For a step-by-step guide on deploying production server with static files, see the demo project.

Optional

To avoid loading the app in each template using {% load component_tags %}, you can add the tag as a 'builtin' in settings.py

TEMPLATES = [
    {
        ...,
        'OPTIONS': {
            'context_processors': [
                ...
            ],
            'builtins': [
                'django_components.templatetags.component_tags',
            ]
        },
    },
]

Read on to find out how to build your first component!

Create your first component

A component in django-components is the combination of four things: CSS, Javascript, a Django template, and some Python code to put them all together.

    sampleproject/
    ├── calendarapp/
    ├── components/             🆕
    │   └── calendar/           🆕
    │       ├── calendar.py     🆕
    │       ├── script.js       🆕
    │       ├── style.css       🆕
    │       └── template.html   🆕
    ├── sampleproject/
    ├── manage.py
    └── requirements.txt

Start by creating empty files in the structure above.

First, you need a CSS file. Be sure to prefix all rules with a unique class so they don't clash with other rules.

/* In a file called [project root]/components/calendar/style.css */
.calendar-component {
  width: 200px;
  background: pink;
}
.calendar-component span {
  font-weight: bold;
}

Then you need a javascript file that specifies how you interact with this component. You are free to use any javascript framework you want. A good way to make sure this component doesn't clash with other components is to define all code inside an anonymous function that calls itself. This makes all variables defined only be defined inside this component and not affect other components.

/* In a file called [project root]/components/calendar/script.js */
(function () {
  if (document.querySelector(".calendar-component")) {
    document.querySelector(".calendar-component").onclick = function () {
      alert("Clicked calendar!");
    };
  }
})();

Now you need a Django template for your component. Feel free to define more variables like date in this example. When creating an instance of this component we will send in the values for these variables. The template will be rendered with whatever template backend you've specified in your Django settings file.

{# In a file called [project root]/components/calendar/template.html #}
<div class="calendar-component">Today's date is <span>{{ date }}</span></div>

Finally, we use django-components to tie this together. Start by creating a file called calendar.py in your component calendar directory. It will be auto-detected and loaded by the app.

Inside this file we create a Component by inheriting from the Component class and specifying the context method. We also register the global component registry so that we easily can render it anywhere in our templates.

## In a file called [project root]/components/calendar/calendar.py
from django_components import Component, register

@register("calendar")
class Calendar(Component):
    # Templates inside `[your apps]/components` dir and `[project root]/components` dir
    # will be automatically found.
    #
    # `template_name` can be relative to dir where `calendar.py` is, or relative to STATICFILES_DIRS
    template_name = "template.html"
    # Or
    def get_template_name(context):
        return f"template-{context['name']}.html"

    # This component takes one parameter, a date string to show in the template
    def get_context_data(self, date):
        return {
            "date": date,
        }

    # Both `css` and `js` can be relative to dir where `calendar.py` is, or relative to STATICFILES_DIRS
    class Media:
        css = "style.css"
        js = "script.js"

And voilá!! We've created our first component.

Syntax highlight and code assistance

Pycharm (or other Jetbrains IDEs)¤

If you're a Pycharm user (or any other editor from Jetbrains), you can have coding assistance as well:

from django_components import Component, register

@register("calendar")
class Calendar(Component):
    def get_context_data(self, date):
        return {
            "date": date,
        }

    # language=HTML
    template= """
        <div class="calendar-component">Today's date is <span>{{ date }}</span></div>
    """

    # language=CSS
    css = """
        .calendar-component { width: 200px; background: pink; }
        .calendar-component span { font-weight: bold; }
    """

    # language=JS
    js = """
        (function(){
            if (document.querySelector(".calendar-component")) {
                document.querySelector(".calendar-component").onclick = function(){ alert("Clicked calendar!"); };
            }
        })()
    """

You don't need to use types.django_html, types.css, types.js since Pycharm uses language injections. You only need to write the comments # language=<lang> above the variables.

Use components outside of templates

New in version 0.81

Components can be rendered outside of Django templates, calling them as regular functions ("React-style").

The component class defines render and render_to_response class methods. These methods accept positional args, kwargs, and slots, offering the same flexibility as the {% component %} tag:

class SimpleComponent(Component):
    template = """
        {% load component_tags %}
        hello: {{ hello }}
        foo: {{ foo }}
        kwargs: {{ kwargs|safe }}
        slot_first: {% slot "first" required / %}
    """

    def get_context_data(self, arg1, arg2, **kwargs):
        return {
            "hello": arg1,
            "foo": arg2,
            "kwargs": kwargs,
        }

rendered = SimpleComponent.render(
    args=["world", "bar"],
    kwargs={"kw1": "test", "kw2": "ooo"},
    slots={"first": "FIRST_SLOT"},
    context={"from_context": 98},
)

Renders:

hello: world
foo: bar
kwargs: {'kw1': 'test', 'kw2': 'ooo'}
slot_first: FIRST_SLOT

SlotFunc¤

When rendering components with slots in render or render_to_response, you can pass either a string or a function.

The function has following signature:

def render_func(
   context: Context,
   data: Dict[str, Any],
   slot_ref: SlotRef,
) -> str | SafeString:
    return nodelist.render(ctx)

• context - Django's Context available to the Slot Node.
• data - Data passed to the {% slot %} tag. See Scoped Slots.
• slot_ref - The default slot content. See Accessing original content of slots.
• NOTE: The slot is lazily evaluated. To render the slot, convert it to string with str(slot_ref).

Example:

def footer_slot(ctx, data, slot_ref):
   return f"""
      SLOT_DATA: {data['abc']}
      ORIGINAL: {slot_ref}
   """

MyComponent.render_to_response(
    slots={
        "footer": footer_slot,
   },
)

Use components as views¤

New in version 0.34

Note: Since 0.92, Component no longer subclasses View. To configure the View class, set the nested Component.View class

Components can now be used as views: - Components define the Component.as_view() class method that can be used the same as View.as_view().

• By default, you can define GET, POST or other HTTP handlers directly on the Component, same as you do with View. For example, you can override get and post to handle GET and POST requests, respectively.

• In addition, Component now has a render_to_response method that renders the component template based on the provided context and slots' data and returns an HttpResponse object.

Modifying the View class¤

The View class that handles the requests is defined on Component.View.

When you define a GET or POST handlers on the Component class, like so:

class MyComponent(Component):
    def get(self, request, *args, **kwargs):
        return self.render_to_response(
            context={
                "date": request.GET.get("date", "2020-06-06"),
            },
        )

    def post(self, request, *args, **kwargs) -> HttpResponse:
        variable = request.POST.get("variable")
        return self.render_to_response(
            kwargs={"variable": variable}
        )

Then the request is still handled by Component.View.get() or Component.View.post() methods. However, by default, Component.View.get() points to Component.get(), and so on.

class ComponentView(View):
    component: Component = None
    ...

    def get(self, request, *args, **kwargs):
        return self.component.get(request, *args, **kwargs)

    def post(self, request, *args, **kwargs):
        return self.component.post(request, *args, **kwargs)

    ...

If you want to define your own View class, you need to: 1. Set the class as Component.View 2. Subclass from ComponentView, so the View instance has access to the component instance.

In the example below, we added extra logic into View.setup().

Note that the POST handler is still defined at the top. This is because View subclasses ComponentView, which defines the post() method that calls Component.post().

If you were to overwrite the View.post() method, then Component.post() would be ignored.

from django_components import Component, ComponentView

class MyComponent(Component):

    def post(self, request, *args, **kwargs) -> HttpResponse:
        variable = request.POST.get("variable")
        return self.component.render_to_response(
            kwargs={"variable": variable}
        )

    class View(ComponentView):
        def setup(self, request, *args, **kwargs):
            super(request, *args, **kwargs)

            do_something_extra(request, *args, **kwargs)

Adding type hints with Generics

New in version 0.92

The Component class optionally accepts type parameters that allow you to specify the types of args, kwargs, slots, and data:

class Button(Component[Args, Kwargs, Data, Slots]):
    ...

• Args - Must be a Tuple or Any
• Kwargs - Must be a TypedDict or Any
• Data - Must be a TypedDict or Any
• Slots - Must be a TypedDict or Any

Here's a full example:

from typing import NotRequired, Tuple, TypedDict, SlotContent, SlotFunc

## Positional inputs
Args = Tuple[int, str]

## Kwargs inputs
class Kwargs(TypedDict):
    variable: str
    another: int
    maybe_var: NotRequired[int] # May be ommited

## Data returned from `get_context_data`
class Data(TypedDict):
    variable: str

## The data available to the `my_slot` scoped slot
class MySlotData(TypedDict):
    value: int

## Slots
class Slots(TypedDict):
    # Use SlotFunc for slot functions.
    # The generic specifies the `data` dictionary
    my_slot: NotRequired[SlotFunc[MySlotData]]
    # SlotContent == Union[str, SafeString]
    another_slot: SlotContent

class Button(Component[Args, Kwargs, Data, Slots]):
    def get_context_data(self, variable, another):
        return {
            "variable": variable,
        }

When you then call Component.render or Component.render_to_response, you will get type hints:

Button.render(
    # Error: First arg must be `int`, got `float`
    args=(1.25, "abc"),
    # Error: Key "another" is missing
    kwargs={
        "variable": "text",
    },
)

Passing additional args or kwargs¤

You may have a function that supports any number of args or kwargs:

def get_context_data(self, *args, **kwargs):
    ...

This is not supported with the typed components.

As a workaround: - For *args, set a positional argument that accepts a list of values:

```py
# Tuple of one member of list of strings
Args = Tuple[List[str]]
```

• For *kwargs, set a keyword argument that accepts a dictionary of values:

  class Kwargs(TypedDict):
      variable: str
      another: int
      # Pass any extra keys under `extra`
      extra: Dict[str, any]
  

Runtime input validation with types¤

New in version 0.96

NOTE: Kwargs, slots, and data validation is supported only for Python >=3.11

In Python 3.11 and later, when you specify the component types, you will get also runtime validation of the inputs you pass to Component.render or Component.render_to_response.

So, using the example from before, if you ignored the type errors and still ran the following code:

Button.render(
    # Error: First arg must be `int`, got `float`
    args=(1.25, "abc"),
    # Error: Key "another" is missing
    kwargs={
        "variable": "text",
    },
)

This would raise a TypeError:

Component 'Button' expected positional argument at index 0 to be <class 'int'>, got 1.25 of type <class 'float'>

In case you need to skip these errors, you can either set the faulty member to Any, e.g.:

## Changed `int` to `Any`
Args = Tuple[Any, str]

Or you can replace Args with Any altogether, to skip the validation of args:

## Replaced `Args` with `Any`
class Button(Component[Any, Kwargs, Data, Slots]):
    ...

Same applies to kwargs, data, and slots.

Dynamic components

If you are writing something like a form component, you may design it such that users give you the component names, and your component renders it.

While you can handle this with a series of if / else statements, this is not an extensible solution.

Instead, you can use dynamic components. Dynamic components are used in place of normal components.

{% load component_tags %}
{% component "dynamic" is=component_name title="Cat Museum" %}
    {% fill "content" %}
        HELLO_FROM_SLOT_1
    {% endfill %}
    {% fill "sidebar" %}
        HELLO_FROM_SLOT_2
    {% endfill %}
{% endcomponent %}

These behave same way as regular components. You pass it the same args, kwargs, and slots as you would to the component that you want to render.

The only exception is that also you supply 1-2 additional inputs: - is - Required - The component name or a component class to render - registry - Optional - The ComponentRegistry that will be searched if is is a component name. If omitted, ALL registries are searched.

By default, the dynamic component is registered under the name "dynamic". In case of a conflict, you can change the name used for the dynamic components by defining the COMPONENTS.dynamic_component_name setting.

If you need to use the dynamic components in Python, you can also import it from django_components:

from django_components import DynamicComponent

comp = SimpleTableComp if is_readonly else TableComp

output = DynamicComponent.render(
    kwargs={
        "is": comp,
        # Other kwargs...
    },
    # args: [...],
    # slots: {...},
)

What is ComponentRegistry

The @register decorator is a shortcut for working with the ComponentRegistry.

ComponentRegistry manages which components can be used in the template tags.

Each ComponentRegistry instance is associated with an instance of Django's Library. And Libraries are inserted into Django template using the {% load %} tags.

The @register decorator accepts an optional kwarg registry, which specifies, the ComponentRegistry to register components into. If omitted, the default ComponentRegistry instance defined in django_components is used.

my_registry = ComponentRegistry()

@register(registry=my_registry)
class MyComponent(Component):
    ...

The default ComponentRegistry is associated with the Library that you load when you call {% load component_tags %} inside your template, or when you add django_components.templatetags.component_tags to the template builtins.

So when you register or unregister a component to/from a component registry, then behind the scenes the registry automatically adds/removes the component's template tags to/from the Library, so you can call the component from within the templates such as {% component "my_comp" %}.

Registering components to custom ComponentRegistry¤

If you are writing a component library to be shared with others, you may want to manage your own instance of ComponentRegistry and register components onto a different Library instance than the default one.

The Library instance can be set at instantiation of ComponentRegistry. If omitted, then the default Library instance from django_components is used.

from django.template import Library
from django_components import ComponentRegistry

my_library = Library(...)
my_registry = ComponentRegistry(library=my_library)

When you have defined your own ComponentRegistry, you can either register the components with my_registry.register(), or pass the registry to the @component.register() decorator via the registry kwarg:

from path.to.my.registry import my_registry

@register("my_component", registry=my_registry)
class MyComponent(Component):
    ...

NOTE: The Library instance can be accessed under library attribute of ComponentRegistry.

Autodiscovery¤

Every component that you want to use in the template with the {% component %} tag needs to be registered with the ComponentRegistry. Normally, we use the @register decorator for that:

from django_components import Component, register

@register("calendar")
class Calendar(Component):
    ...

But for the component to be registered, the code needs to be executed - the file needs to be imported as a module.

One way to do that is by importing all your components in apps.py:

from django.apps import AppConfig

class MyAppConfig(AppConfig):
    name = "my_app"

    def ready(self) -> None:
        from components.card.card import Card
        from components.list.list import List
        from components.menu.menu import Menu
        from components.button.button import Button
        ...

However, there's a simpler way!

By default, the Python files in the STATICFILES_DIRS directories are auto-imported in order to auto-register the components.

Autodiscovery occurs when Django is loaded, during the ready hook of the apps.py file.

If you are using autodiscovery, keep a few points in mind:

• Avoid defining any logic on the module-level inside the components dir, that you would not want to run anyway.
• Components inside the auto-imported files still need to be registered with @register()
• Auto-imported component files must be valid Python modules, they must use suffix .py, and module name should follow PEP-8.

Autodiscovery can be disabled in the settings.

Using slots in templates¤

New in version 0.26:

• The slot tag now serves only to declare new slots inside the component template.
• To override the content of a declared slot, use the newly introduced fill tag instead.
• Whereas unfilled slots used to raise a warning, filling a slot is now optional by default.
• To indicate that a slot must be filled, the new required option should be added at the end of the slot tag.

Components support something called 'slots'. When a component is used inside another template, slots allow the parent template to override specific parts of the child component by passing in different content. This mechanism makes components more reusable and composable. This behavior is similar to slots in Vue.

In the example below we introduce two block tags that work hand in hand to make this work. These are...

• {% slot <name> %}/{% endslot %}: Declares a new slot in the component template.
• {% fill <name> %}/{% endfill %}: (Used inside a component tag pair.) Fills a declared slot with the specified content.

Let's update our calendar component to support more customization. We'll add slot tag pairs to its template, template.html.

<div class="calendar-component">
    <div class="header">
        {% slot "header" %}Calendar header{% endslot %}
    </div>
    <div class="body">
        {% slot "body" %}Today's date is <span>{{ date }}</span>{% endslot %}
    </div>
</div>

When using the component, you specify which slots you want to fill and where you want to use the defaults from the template. It looks like this:

{% component "calendar" date="2020-06-06" %}
    {% fill "body" %}Can you believe it's already <span>{{ date }}</span>??{% endfill %}
{% endcomponent %}

Since the 'header' fill is unspecified, it's taken from the base template. If you put this in a template, and pass in date=2020-06-06, this is what gets rendered:

<div class="calendar-component">
    <div class="header">
        Calendar header
    </div>
    <div class="body">
        Can you believe it's already <span>2020-06-06</span>??
    </div>
</div>

Render fill in multiple places¤

Added in version 0.70

You can render the same content in multiple places by defining multiple slots with identical names:

<div class="calendar-component">
    <div class="header">
        {% slot "image" %}Image here{% endslot %}
    </div>
    <div class="body">
        {% slot "image" %}Image here{% endslot %}
    </div>
</div>

So if used like:

{% component "calendar" date="2020-06-06" %}
    {% fill "image" %}
        <img src="..." />
    {% endfill %}
{% endcomponent %}

This renders:

<div class="calendar-component">
    <div class="header">
        <img src="..." />
    </div>
    <div class="body">
        <img src="..." />
    </div>
</div>

Accessing original content of slots¤

Added in version 0.26

NOTE: In version 0.77, the syntax was changed from

{% fill "my_slot" as "alias" %} {{ alias.default }}

to

{% fill "my_slot" default="slot_default" %} {{ slot_default }}

Sometimes you may want to keep the original slot, but only wrap or prepend/append content to it. To do so, you can access the default slot via the default kwarg.

Similarly to the data attribute, you specify the variable name through which the default slot will be made available.

For instance, let's say you're filling a slot called 'body'. To render the original slot, assign it to a variable using the 'default' keyword. You then render this variable to insert the default content:

{% component "calendar" date="2020-06-06" %}
    {% fill "body" default="body_default" %}
        {{ body_default }}. Have a great day!
    {% endfill %}
{% endcomponent %}

This produces:

<div class="calendar-component">
    <div class="header">
        Calendar header
    </div>
    <div class="body">
        Today's date is <span>2020-06-06</span>. Have a great day!
    </div>
</div>

Accessing is_filled of slot names with special characters¤

To be able to access a slot name via component_vars.is_filled, the slot name needs to be composed of only alphanumeric characters and underscores (e.g. this__isvalid_123).

However, you can still define slots with other special characters. In such case, the slot name in component_vars.is_filled is modified to replace all invalid characters into _.

So a slot named "my super-slot :)" will be available as component_vars.is_filled.my_super_slot___.

Passing data to slots¤

To pass the data to the slot tag, simply pass them as keyword attributes (key=value):

@register("my_comp")
class MyComp(Component):
    template = """
        <div>
            {% slot "content" default input=input %}
                input: {{ input }}
            {% endslot %}
        </div>
    """

    def get_context_data(self, input):
        processed_input = do_something(input)
        return {
            "input": processed_input,
        }

Dynamic slots and fills¤

Until now, we were declaring slot and fill names statically, as a string literal, e.g.

{% slot "content" / %}

However, sometimes you may want to generate slots based on the given input. One example of this is a table component like that of Vuetify, which creates a header and an item slots for each user-defined column.

In django_components you can achieve the same, simply by using a variable (or a template expression) instead of a string literal:

<table>
  <tr>
    {% for header in headers %}
      <th>
        {% slot "header-{{ header.key }}" value=header.title %}
          {{ header.title }}
        {% endslot %}
      </th>
    {% endfor %}
  </tr>
</table>

When using the component, you can either set the fill explicitly:

{% component "table" headers=headers items=items %}
  {% fill "header-name" data="data" %}
    <b>{{ data.value }}</b>
  {% endfill %}
{% endcomponent %}

Or also use a variable:

{% component "table" headers=headers items=items %}
  {# Make only the active column bold #}
  {% fill "header-{{ active_header_name }}" data="data" %}
    <b>{{ data.value }}</b>
  {% endfill %}
{% endcomponent %}

NOTE: It's better to use static slot names whenever possible for clarity. The dynamic slot names should be reserved for advanced use only.

Lastly, in rare cases, you can also pass the slot name via the spread operator. This is possible, because the slot name argument is actually a shortcut for a name keyword argument.

So this:

{% slot "content" / %}

is the same as:

{% slot name="content" / %}

So it's possible to define a name key on a dictionary, and then spread that onto the slot tag:

{# slot_props = {"name": "content"} #}
{% slot ...slot_props / %}

Rendering HTML attributes

New in version 0.74:

You can use the html_attrs tag to render HTML attributes, given a dictionary of values.

So if you have a template:

<div class="{{ classes }}" data-id="{{ my_id }}">
</div>

You can simplify it with html_attrs tag:

<div {% html_attrs attrs %}>
</div>

where attrs is:

attrs = {
    "class": classes,
    "data-id": my_id,
}

This feature is inspired by merge_attrs tag of django-web-components and "fallthrough attributes" feature of Vue.

Boolean attributes¤

In HTML, boolean attributes are usually rendered with no value. Consider the example below where the first button is disabled and the second is not:

<button disabled>Click me!</button> <button>Click me!</button>

HTML rendering with html_attrs tag or attributes_to_string works the same way, where key=True is rendered simply as key, and key=False is not render at all.

So given this input:

attrs = {
    "disabled": True,
    "autofocus": False,
}

And template:

<div {% html_attrs attrs %}>
</div>

Then this renders:

<div disabled></div>

Appending attributes¤

For the class HTML attribute, it's common that we want to join multiple values, instead of overriding them. For example, if you're authoring a component, you may want to ensure that the component will ALWAYS have a specific class. Yet, you may want to allow users of your component to supply their own classes.

We can achieve this by adding extra kwargs. These values will be appended, instead of overwriting the previous value.

So if we have a variable attrs:

attrs = {
    "class": "my-class pa-4",
}

And on html_attrs tag, we set the key class:

<div {% html_attrs attrs class="some-class" %}>
</div>

Then these will be merged and rendered as:

<div data-value="my-class pa-4 some-class"></div>

To simplify merging of variables, you can supply the same key multiple times, and these will be all joined together:

{# my_var = "class-from-var text-red" #}
<div {% html_attrs attrs class="some-class another-class" class=my_var %}>
</div>

Renders:

<div
  data-value="my-class pa-4 some-class another-class class-from-var text-red"
></div>

Examples for html_attrs¤

Assuming that:

class_from_var = "from-var"

attrs = {
    "class": "from-attrs",
    "type": "submit",
}

defaults = {
    "class": "from-defaults",
    "role": "button",
}

Then:

• Empty tag
  {% html_attr %}

renders (empty string):

• Only kwargs
  {% html_attr class="some-class" class=class_from_var data-id="123" %}

renders:
class="some-class from-var" data-id="123"

• Only attrs
  {% html_attr attrs %}

renders:
class="from-attrs" type="submit"

• Attrs as kwarg
  {% html_attr attrs=attrs %}

renders:
class="from-attrs" type="submit"

• Only defaults (as kwarg)
  {% html_attr defaults=defaults %}

renders:
class="from-defaults" role="button"

• Attrs using the prefix:key=value construct
  {% html_attr attrs:class="from-attrs" attrs:type="submit" %}

renders:
class="from-attrs" type="submit"

• Defaults using the prefix:key=value construct
  {% html_attr defaults:class="from-defaults" %}

renders:
class="from-defaults" role="button"

• All together (1) - attrs and defaults as positional args:
  {% html_attrs attrs defaults class="added_class" class=class_from_var data-id=123 %}

renders:
class="from-attrs added_class from-var" type="submit" role="button" data-id=123

• All together (2) - attrs and defaults as kwargs args:
  {% html_attrs class="added_class" class=class_from_var data-id=123 attrs=attrs defaults=defaults %}

renders:
class="from-attrs added_class from-var" type="submit" role="button" data-id=123

• All together (3) - mixed:
  {% html_attrs attrs defaults:class="default-class" class="added_class" class=class_from_var data-id=123 %}

renders:
class="from-attrs added_class from-var" type="submit" data-id=123

Rendering HTML attributes outside of templates¤

If you need to use serialize HTML attributes outside of Django template and the html_attrs tag, you can use attributes_to_string:

from django_components.attributes import attributes_to_string

attrs = {
    "class": "my-class text-red pa-4",
    "data-id": 123,
    "required": True,
    "disabled": False,
    "ignored-attr": None,
}

attributes_to_string(attrs)
## 'class="my-class text-red pa-4" data-id="123" required'

Self-closing tags

When you have a tag like {% component %} or {% slot %}, but it has no content, you can simply append a forward slash / at the end, instead of writing out the closing tags like {% endcomponent %} or {% endslot %}:

So this:

{% component "button" %}{% endcomponent %}

becomes

{% component "button" / %}

Spread operator¤

New in version 0.93:

Instead of passing keyword arguments one-by-one:

{% component "calendar" title="How to abc" date="2015-06-19" author="John Wick" / %}

You can use a spread operator ...dict to apply key-value pairs from a dictionary:

post_data = {
    "title": "How to...",
    "date": "2015-06-19",
    "author": "John Wick",
}

{% component "calendar" ...post_data / %}

This behaves similar to JSX's spread operator or Vue's v-bind.

Spread operators are treated as keyword arguments, which means that: 1. Spread operators must come after positional arguments. 2. You cannot use spread operators for positional-only arguments.

Other than that, you can use spread operators multiple times, and even put keyword arguments in-between or after them:

{% component "calendar" ...post_data id=post.id ...extra / %}

In a case of conflicts, the values added later (right-most) overwrite previous values.

Passing data as string vs original values¤

Sometimes you may want to use the template tags to transform or generate the data that is then passed to the component.

The data doesn't necessarily have to be strings. In the example above, the kwarg id was passed as an integer, NOT a string.

Although the string literals for components inputs are treated as regular Django templates, there is one special case:

When the string literal contains only a single template tag, with no extra text, then the value is passed as the original type instead of a string.

Here, page is an integer:

{% component 'blog_post' page="{% random_int 10 20 %}" / %}

Here, page is a string:

{% component 'blog_post' page=" {% random_int 10 20 %} " / %}

And same applies to the {{ }} variable tags:

Here, items is a list:

{% component 'cat_list' items="{{ cats|slice:':2' }}" / %}

Here, items is a string:

{% component 'cat_list' items="{{ cats|slice:':2' }} See more" / %}

Pass dictonary by its key-value pairs¤

New in version 0.74:

Sometimes, a component may expect a dictionary as one of its inputs.

Most commonly, this happens when a component accepts a dictionary of HTML attributes (usually called attrs) to pass to the underlying template.

In such cases, we may want to define some HTML attributes statically, and other dynamically. But for that, we need to define this dictionary on Python side:

@register("my_comp")
class MyComp(Component):
    template = """
        {% component "other" attrs=attrs / %}
    """

    def get_context_data(self, some_id: str):
        attrs = {
            "class": "pa-4 flex",
            "data-some-id": some_id,
            "@click.stop": "onClickHandler",
        }
        return {"attrs": attrs}

But as you can see in the case above, the event handler @click.stop and styling pa-4 flex are disconnected from the template. If the component grew in size and we moved the HTML to a separate file, we would have hard time reasoning about the component's template.

Luckily, there's a better way.

When we want to pass a dictionary to a component, we can define individual key-value pairs as component kwargs, so we can keep all the relevant information in the template. For that, we prefix the key with the name of the dict and :. So key class of input attrs becomes attrs:class. And our example becomes:

@register("my_comp")
class MyComp(Component):
    template = """
        {% component "other"
            attrs:class="pa-4 flex"
            attrs:data-some-id=some_id
            attrs:@click.stop="onClickHandler"
        / %}
    """

    def get_context_data(self, some_id: str):
        return {"some_id": some_id}

Sweet! Now all the relevant HTML is inside the template, and we can move it to a separate file with confidence:

{% component "other"
    attrs:class="pa-4 flex"
    attrs:data-some-id=some_id
    attrs:@click.stop="onClickHandler"
/ %}

Note: It is NOT possible to define nested dictionaries, so attrs:my_key:two=2 would be interpreted as:

{"attrs": {"my_key:two": 2}}

Prop drilling and dependency injection (provide / inject)¤

New in version 0.80:

Django components supports dependency injection with the combination of:

1. {% provide %} tag
2. inject() method of the Component class

How to use provide / inject¤

As the name suggest, using provide / inject consists of 2 steps

1. Providing data
2. Injecting provided data

For examples of advanced uses of provide / inject, see this discussion.

Using inject() method¤

To "inject" (access) the data defined on the provide tag, you can use the inject() method inside of get_context_data().

For a component to be able to "inject" some data, the component ({% component %} tag) must be nested inside the {% provide %} tag.

In the example from previous section, we've defined two kwargs: key="hi" another=123. That means that if we now inject "my_data", we get an object with 2 attributes - key and another.

class ChildComponent(Component):
    def get_context_data(self):
        my_data = self.inject("my_data")
        print(my_data.key)     # hi
        print(my_data.another) # 123
        return {}

First argument to inject is the key (or name) of the provided data. This must match the string that you used in the provide tag. If no provider with given key is found, inject raises a KeyError.

To avoid the error, you can pass a second argument to inject to which will act as a default value, similar to dict.get(key, default):

class ChildComponent(Component):
    def get_context_data(self):
        my_data = self.inject("invalid_key", DEFAULT_DATA)
        assert my_data == DEFAUKT_DATA
        return {}

The instance returned from inject() is a subclass of NamedTuple, so the instance is immutable. This ensures that the data returned from inject will always have all the keys that were passed to the provide tag.

NOTE: inject() works strictly only in get_context_data. If you try to call it from elsewhere, it will raise an error.

Component hooks¤

New in version 0.96

Component hooks are functions that allow you to intercept the rendering process at specific positions.

Component hooks example¤

You can use hooks together with provide / inject to create components that accept a list of items via a slot.

In the example below, each tab_item component will be rendered on a separate tab page, but they are all defined in the default slot of the tabs component.

See here for how it was done

{% component "tabs" %}
  {% 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 %}

Pre-defined template variables

Here is a list of all variables that are automatically available from within the component's template and on_render_before / on_render_after hooks.

• component_vars.is_filled

  New in version 0.70

  Dictonary describing which slots are filled (True) or are not (False).

  Example:

  {% if component_vars.is_filled.my_slot %}
      {% slot "my_slot" / %}
  {% endif %}
  

Available TagFormatters

django_components provides following predefined TagFormatters:

• ComponentFormatter (django_components.component_formatter)

  Default

  Uses the component and endcomponent tags, and the component name is gives as the first positional argument.

  Example as block:

  {% component "button" href="..." %}
      {% fill "content" %}
          ...
      {% endfill %}
  {% endcomponent %}
  

  Example as inlined tag:

  {% component "button" href="..." / %}
  

• ShorthandComponentFormatter (django_components.shorthand_component_formatter)

  Uses the component name as start tag, and end<component_name> as an end tag.

  Example as block:

  {% button href="..." %}
      Click me!
  {% endbutton %}
  

  Example as inlined tag:

  {% button href="..." / %}
  

Background¤

First, let's discuss how TagFormatters work, and how components are rendered in django_components.

When you render a component with {% component %} (or your own tag), the following happens: 1. component must be registered as a Django's template tag 2. Django triggers django_components's tag handler for tag component. 3. The tag handler passes the tag contents for pre-processing to TagFormatter.parse().

So if you render this:
```django
{% component "button" href="..." disabled %}
{% endcomponent %}
```

Then `TagFormatter.parse()` will receive a following input:
```py
["component", '"button"', 'href="..."', 'disabled']
```

1. TagFormatter extracts the component name and the remaining input.

   So, given the above, TagFormatter.parse() returns the following:

   TagResult(
       component_name="button",
       tokens=['href="..."', 'disabled']
   )
   

   5. The tag handler resumes, using the tokens returned from TagFormatter.

   So, continuing the example, at this point the tag handler practically behaves as if you rendered:

   {% component href="..." disabled %}
   

   6. Tag handler looks up the component button, and passes the args, kwargs, and slots to it.

Defining HTML/JS/CSS files¤

django_component's management of files builds on top of Django's Media class.

To be familiar with how Django handles static files, we recommend reading also:

• How to manage static files (e.g. images, JavaScript, CSS)

Defining multiple paths¤

Each component can have only a single template. However, you can define as many JS or CSS files as you want using a list.

class MyComponent(Component):
    class Media:
        js = ["path/to/script1.js", "path/to/script2.js"]
        css = ["path/to/style1.css", "path/to/style2.css"]

Supported types for file paths¤

File paths can be any of:

• str
• bytes
• PathLike (__fspath__ method)
• SafeData (__html__ method)
• Callable that returns any of the above, evaluated at class creation (__new__)

from pathlib import Path

from django.utils.safestring import mark_safe

class SimpleComponent(Component):
    class Media:
        css = [
            mark_safe('<link href="/static/calendar/style.css" rel="stylesheet" />'),
            Path("calendar/style1.css"),
            "calendar/style2.css",
            b"calendar/style3.css",
            lambda: "calendar/style4.css",
        ]
        js = [
            mark_safe('<script src="/static/calendar/script.js"></script>'),
            Path("calendar/script1.js"),
            "calendar/script2.js",
            b"calendar/script3.js",
            lambda: "calendar/script4.js",
        ]

Customize how paths are rendered into HTML tags with media_class¤

Sometimes you may need to change how all CSS <link> or JS <script> tags are rendered for a given component. You can achieve this by providing your own subclass of Django's Media class to component's media_class attribute.

Normally, the JS and CSS paths are passed to Media class, which decides how the paths are resolved and how the <link> and <script> tags are constructed.

To change how the tags are constructed, you can override the Media.render_js and Media.render_css methods:

from django.forms.widgets import Media
from django_components import Component, register

class MyMedia(Media):
    # Same as original Media.render_js, except
    # the `<script>` tag has also `type="module"`
    def render_js(self):
        tags = []
        for path in self._js:
            if hasattr(path, "__html__"):
                tag = path.__html__()
            else:
                tag = format_html(
                    '<script type="module" src="{}"></script>',
                    self.absolute_path(path)
                )
        return tags

@register("calendar")
class Calendar(Component):
    template_name = "calendar/template.html"

    class Media:
        css = "calendar/style.css"
        js = "calendar/script.js"

    # Override the behavior of Media class
    media_class = MyMedia

NOTE: The instance of the Media class (or it's subclass) is available under Component.media after the class creation (__new__).

Setting Up ComponentDependencyMiddleware

ComponentDependencyMiddleware is a Django middleware designed to manage and inject CSS/JS dependencies for rendered components dynamically. It ensures that only the necessary stylesheets and scripts are loaded in your HTML responses, based on the components used in your Django templates.

To set it up, add the middleware to your MIDDLEWARE in settings.py:

MIDDLEWARE = [
    # ... other middleware classes ...
    'django_components.middleware.ComponentDependencyMiddleware'
    # ... other middleware classes ...
]

Then, enable RENDER_DEPENDENCIES in setting.py:

COMPONENTS = {
    "RENDER_DEPENDENCIES": True,
    # ... other component settings ...
}

libraries - Load component modules

Configure the locations where components are loaded. To do this, add a COMPONENTS variable to you settings.py with a list of python paths to load. This allows you to build a structure of components that are independent from your apps.

COMPONENTS = {
    "libraries": [
        "mysite.components.forms",
        "mysite.components.buttons",
        "mysite.components.cards",
    ],
}

Where mysite/components/forms.py may look like this:

@register("form_simple")
class FormSimple(Component):
    template = """
        <form>
            ...
        </form>
    """

@register("form_other")
class FormOther(Component):
    template = """
        <form>
            ...
        </form>
    """

In the rare cases when you need to manually trigger the import of libraries, you can use the import_libraries function:

from django_components import import_libraries

import_libraries()

dynamic_component_name¤

By default, the dynamic component is registered under the name "dynamic". In case of a conflict, use this setting to change the name used for the dynamic components.

COMPONENTS = {
    "dynamic_component_name": "new_dynamic",
}

template_cache_size - Tune the template cache¤

Each time a template is rendered it is cached to a global in-memory cache (using Python's lru_cache decorator). This speeds up the next render of the component. As the same component is often used many times on the same page, these savings add up.

By default the cache holds 128 component templates in memory, which should be enough for most sites. But if you have a lot of components, or if you are using the template method of a component to render lots of dynamic templates, you can increase this number. To remove the cache limit altogether and cache everything, set template_cache_size to None.

COMPONENTS = {
    "template_cache_size": 256,
}

If you want add templates to the cache yourself, you can use cached_template():

from django_components import cached_template

cached_template("Variable: {{ variable }}")

## You can optionally specify Template class, and other Template inputs:
class MyTemplate(Template):
    pass

cached_template(
    "Variable: {{ variable }}",
    template_cls=MyTemplate,
    name=...
    origin=...
    engine=...
)

Example "django"¤

Given this template:

class RootComp(Component):
    template = """
        {% with cheese="feta" %}
            {% component 'my_comp' %}
                {{ my_var }}  # my_var
                {{ cheese }}  # cheese
            {% endcomponent %}
        {% endwith %}
    """
    def get_context_data(self):
        return { "my_var": 123 }

Then if get_context_data() of the component "my_comp" returns following data:

{ "my_var": 456 }

Then the template will be rendered as:

456   # my_var
feta  # cheese

Because "my_comp" overshadows the variable "my_var", so {{ my_var }} equals 456.

And variable "cheese" equals feta, because the fill CAN access all the data defined in the outer layers, like the {% with %} tag.

reload_on_template_change - Reload dev server on component file changes¤

If True, configures Django to reload on component files. See Reload dev server on component file changes.

NOTE: This setting should be enabled only for the dev environment!

Running with development server¤

Logging and debugging¤

Django components supports logging with Django. This can help with troubleshooting.

To configure logging for Django components, set the django_components logger in LOGGING in settings.py (below).

Also see the settings.py file in sampleproject for a real-life example.

import logging
import sys

LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,
    "handlers": {
        "console": {
            'class': 'logging.StreamHandler',
            'stream': sys.stdout,
        },
    },
    "loggers": {
        "django_components": {
            "level": logging.DEBUG,
            "handlers": ["console"],
        },
    },
}

Management Command Usage

To use the command, run the following command in your terminal:

python manage.py startcomponent <name> --path <path> --js <js_filename> --css <css_filename> --template <template_filename> --force --verbose --dry-run

Replace <name>, <path>, <js_filename>, <css_filename>, and <template_filename> with your desired values.

Creating a Component with Default Settings¤

To create a component with the default settings, you only need to provide the name of the component:

python manage.py startcomponent my_component

This will create a new component named my_component in the components directory of your Django project. The JavaScript, CSS, and template files will be named script.js, style.css, and template.html, respectively.

Overwriting an Existing Component¤

If you want to overwrite an existing component, you can use the --force option:

python manage.py startcomponent my_component --force

This will overwrite the existing my_component if it exists.

Writing and sharing component libraries¤

You can publish and share your components for others to use. Here are the steps to do so:

Publishing component libraries¤

Once you are ready to share your library, you need to build a distribution and then publish it to PyPI.

django_components uses the build utility to build a distribution:

python -m build --sdist --wheel --outdir dist/ .

And to publish to PyPI, you can use twine (See Python user guide)

twine upload --repository pypi dist/* -u __token__ -p <PyPI_TOKEN>

Notes on publishing: - The user of the package NEEDS to have installed and configured django_components. - If you use components where the HTML / CSS / JS files are separate, you may need to define MANIFEST.in to include those files with the distribution (see user guide).

Community examples¤

One of our goals with django-components is to make it easy to share components between projects. If you have a set of components that you think would be useful to others, please open a pull request to add them to the list below.

• django-htmx-components: A set of components for use with htmx. Try out the live demo.

Install locally and run the tests

Start by forking the project by clicking the Fork button up in the right corner in the GitHub . This makes a copy of the repository in your own name. Now you can clone this repository locally and start adding features:

git clone https://github.com/<your GitHub username>/django-components.git

To quickly run the tests install the local dependencies by running:

pip install -r requirements-dev.txt

Now you can run the tests to make sure everything works as expected:

pytest

The library is also tested across many versions of Python and Django. To run tests that way:

pyenv install -s 3.8
pyenv install -s 3.9
pyenv install -s 3.10
pyenv install -s 3.11
pyenv install -s 3.12
pyenv local 3.8 3.9 3.10 3.11 3.12
tox -p

Development guides¤

• Slot rendering flot