Build reusable components in Django without writing a single line of Python.

from htmx.org

htmx gives you access to AJAX, CSS Transitions, WebSockets and Server Sent Events directly in HTML, using attributes, so you can build modern user interfaces with the simplicity and power of hypertext

htmx attributes are represented in templates tags like other attributes. potential caveat : they are defined with a hyphen hx-get , hx-target, hx-swap ...

this enhancement could also increase compatibility with alpine, hyperscript and other frameworks that make use of custom HTML attributes, and attrs that are defined with hyphens such as aria-label

Happy to contribute to implementation

Hi,

Trying to marry Slippers with AlpineJS I found that attributes starting with @ do not render.

Component definition:

<button {% attrs type @click %}>{{ children }}</button>

Usage:

{% #button type="button" @click="open = true" %}Open something{% /button %}

Render:

<button>Open something</button>

It's not even rendering the type attribute

Poetry will not accept to install Django 4.1 with slippers (any version).

$ poetry lock
Updating dependencies
Resolving dependencies... (1.5s)

  SolverProblemError

  Because no versions of slippers match <0.1.0 || >0.1.0,<0.1.1 || >0.1.1,<0.1.2 || >0.1.2,<0.1.3 || >0.1.3,<0.1.4 || >0.1.4,<0.2.0 || >0.2.0,<0.3.0 || >0.3.0,<0.3.1 || >0.3.1
   and slippers (0.1.0) depends on Django (>=3.0,<4.0), slippers (<0.1.1 || >0.1.1,<0.1.2 || >0.1.2,<0.1.3 || >0.1.3,<0.1.4 || >0.1.4,<0.2.0 || >0.2.0,<0.3.0 || >0.3.0,<0.3.1 || >0.3.1) requires Django (>=3.0,<4.0).
  And because slippers (0.1.1) depends on Django (>=2.2,<4.0), slippers (<0.1.2 || >0.1.2,<0.1.3 || >0.1.3,<0.1.4 || >0.1.4,<0.2.0 || >0.2.0,<0.3.0 || >0.3.0,<0.3.1 || >0.3.1) requires Django (>=2.2,<4.0).
  And because slippers (0.1.2) depends on Django (>=2.2,<4.0)
   and slippers (0.1.3) depends on Django (>=2.2,<4.0), slippers (<0.1.4 || >0.1.4,<0.2.0 || >0.2.0,<0.3.0 || >0.3.0,<0.3.1 || >0.3.1) requires Django (>=2.2,<4.0).
  And because slippers (0.1.4) depends on Django (>=2.2,<4.0)
   and slippers (0.2.0) depends on Django (>=2.2,<4.0), slippers (<0.3.0 || >0.3.0,<0.3.1 || >0.3.1) requires Django (>=2.2,<4.0).
  And because slippers (0.3.0) depends on Django (>=2.2,<4.0)
   and slippers (0.3.1) depends on Django (>=2.2,<4.1), every version of slippers requires Django (>=2.2,<4.1).
  So, because mango depends on both Django (4.1.*) and slippers (*), version solving failed.

This is with slippers 0.4.0.

Consider the following simple component, named test_component:

<input type="text" {% attrs required maxlength %}>

If you use it in a template like this:

{% test_component required maxlength=10 %}

...then it outputs this (note that the maxlength attribute is missing):

<input type="text" required>

But if you reverse the order of the attributes in the template:

{% test_component maxlength=10 required %}

Or if you pass an explicit value:

{% test_component required=True maxlength=10 %}

...then it works as expected:

<input type="text" required maxlength="10">

Firstly, thank you for your work on Slippers!

I've looked through the documentation and can't find something directly answering this question.

Assume I have a base template similar to the following:

// base.html
<div class="mobile-menu">{% block menu_mobile %}{% endblock %}</div>
<div class="wrapper">
  <div class="desktop-menu">{% block menu_desktop %}{% endblock %}</div>
  <div class="content">{% block content %}{% endblock %}</div>
</div>

Note that since blocks must have unique names, I'm enable to directly repeat that content despite wanting the exact same markup.

I would LOVE to be able to use fragments outside of a block, like so:

// some-page.html
{% extends 'base.html' %}
{% fragment as menu %}
  <ul>
    <li><a href="#">My DRY Menu</a></li>
  </ul>
{% endfragment %}
{% block menu_mobile %}{{ menu }}{% endblock %}
{% block menu_desktop %}{{ menu }}{% endblock %}
{% block content %}
  My content here 
{% endblock %}

Unfortunately this isn't working in my experimentation. I'm guessing this is a scoping issue with block, but figured it was worth confirming whether this is possible.

Thanks for your time.

Slippers using PyYAML ^5.4.1 is causing dependency conflicts with other PyYAML-using packages in a project of mine. It appears that the only backwards-incompatible change from PyYAML 5 to 6 is dropping support for Python 2, so it is compatible with slippers.

https://github.com/mixxorz/slippers/blob/2b0c9b42e6f78e9bad3903816c8becae870b26f4/slippers/apps.py#L43 Looks like this line could be updated to find either a yaml or yml file 😃.

select_template https://docs.djangoproject.com/en/3.2/ref/templates/api/#django.template.Engine.select_template

Hi

I really liked this component approach that slippers does, an idea came to me for a component to have more than one child. Do you think this would have adoption in the lib? I can think of some ideas for that.

When I tried out Slippers it didn't work initially because I had created a "components.yml" file instead of "components.yaml". I didn't see the system check message either because the log statements already moved it too far up the terminal.

I'm not sure what suffix is more widely used but, for example, Docker Compose refers its config as "docker-compose.yml" while suporting both file endings:

The Compose file is a YAML file defining services, networks and volumes. The default path for a Compose file is ./docker-compose.yml.

Tip: You can use either a .yml or .yaml extension for this file. They both work.

Fixes issues where arbitrary props declared in front matter are type checked. Changed this behaviour so that only the values explicitly passed into the component via the component's template tag are evaluated.

This PR:

• Adds a way to define prop types
• Adds a way to define default values for props
• Adds optional runtime type checking
• Adds a way to add custom Python code to components

Example component:

---
props.types = {
    'required_string': str,
    'optional_number': Optional[int],
    'default_number': int,
}
props.defaults = {
    'default_number': 10,
}

# Arbitrary Python code that adds variables to the template context
props['new_number'] = props['default_number'] * 2

# props['default_number'] will return 10 if `default_number` is not passed to the component.
---

The context contains:

Required string: {{ required_string }}
Optional number: {{ optional_number }}
Default number: {{ default_number }}
New number: {{ new_number }}

• Only display prop errors when runtime checking is enabled
• Refactor how console errors are reported
• Update padding on modal overlay
• Remove shell error output target and rich dependency

Hello creator(s) of Slippers!

I have heard about your project from this guy on YouTube, BugBytes: https://www.youtube.com/watch?v=oC1K8IKK3Vo

I was excited to use it but was disappointed to see my IDE (IntelliJ) refusing to accept the newly created template tags.

Prefixing any tag with a special character (besides underscores _ and dashes - ) throws out errors from the inspector.

After days of trying, I haven't found a way to disable the inspector for that specific error. Nor could I register the symbol-containing tags by creating some kind of new rule. It just didn't work.

I just lived with it, but after a couple of days of writing templates full of fake errors, I got so bugged out that I gave up and looked for an alternative.

Then I found django-components, which did a similar job to Slippers, but in my opinion, is way too verbose and so I came back to slippers.

Unfortunately, picking up another IDE is not an option after years of getting used to it. So this time, I tried to fix this issue by monkey-patching the code inside templatetags/slippers.py (really ran out of options).

OPENING_SYMBOL = "__"
CLOSING_SYMBOL = "___"


# Copied from slippers source code
#
# Replaces opening / closing symbols for tags
# #card and /card --> __card and ___card
#
# Fixes IntelliJ IDE template inspector throwing errors

# Component tags
def create_component_tag(template_path):
    def do_component(parser, token):
        tag_name, *remaining_bits = token.split_contents()

        # Block components start with OPENING_SYMBOL
        # Expect a closing tag
        if tag_name.startswith(OPENING_SYMBOL):
            nodelist = parser.parse((f"{CLOSING_SYMBOL}{tag_name[len(CLOSING_SYMBOL):]}",))
            parser.delete_first_token()
        else:
            nodelist = None

For motives unbeknownst to me, the template tags won't be registered when applying this monkey patch, but I have not given up on this solution yet and would come up with a pull request once everything is working well.

Any chance of adding the option to change the template tag prefixes (possibly using a settings.py variable)?

Massive respect for creating this library, Chris, a slippers fan :)

I found that we can provide a default value to attrs tag values using the var tag I'm not sure if it was initially designed to work like that.

This PR is about documenting that find.

This issue proposes changing the suggested name format of components to TitleCase from snake_case to improve readability by being distinct from normal template tags, keyword arguments, and variables.

{% #Quote %}
  {% QuotePhoto src="/project-hail-mary.jpg" %}

  {% #QuoteText %}
    “I penetrated the outer cell membrane with a nanosyringe."
    "You poked it with a stick?"
    "No!" I said. "Well. Yes. But it was a scientific poke
    with a very scientific stick.”
  {% /QuoteText %}

  {% #QuoteAttribution %}
    Andy Weir, Project Hail Mary
  {% /QuoteAttribution %}
{% /Quote %}

Open to feedback on this.

Maintaining a yaml file of components is a little annoying. There should be a built-in way to auto-discover components.

I have a few ideas but if you have suggestions, please share. 🙂