Slot/fill names must be strings change

[timothyis]

I've just upgraded out Django project to use django-components 0.27.1 and there is a lot of breaking changes, most of which are related to the fact that I've used slots as I would blocks, e.g.,

{% component_block "menu" %}
    {% fill items %}
        <a href="#">Some item</a>
    {% endslot items %}
{% endcomponent_block %}

The same is true of when I define a component with slots, instead of fills.

I liked doing this since when content gets long and there are multiple slots, it acts as a good way to document where they start and end without comments.

It's the same as when you use block/endblock.

What was the reason for changing this?

[lemontheme]

Hi there, sorry to hear this change is causing you problems!

What you're observing is indeed the result of a conscious decision to treat the first argument to slot and fill tags as a variable rather than as a literal identifier.

It was something that came up in the course of PR #221, where you'll find a record of the decision making process. I'll try to give a summary here.

• With the introduction of fill tags, the 'slots are like blocks' analogy broke down. Slots no longer override slots on some parent template. Instead, the new fill tags co-ordinate with slot tags in a way that no longer resembles the inheritance-based approach of block tags. Mimicing the block way of parsing tag arguments, then, became less important.
• The first/'name' argument to component_block has been treated as a variable since many versions, meaning if you want a literal string, you need to use quotes. Allowing variables here lets you specify components at render time by passing in the concrete component name as part of the render context. It also lets you use component names that aren't valid python identifiers.
• We figured that, if the first argument to component_block is already treated as a variable, we might as well extend it to all tags. This has two major advantages and one silly drawback:
  • Advantages:
    1. Fill tags can be made to target specific slots dynamically (again by means of the render context).
    2. It's easier to remember one rule – 'all literal names should be quoted' – than to have to remember different rules for each tag.
  • Drawback: There are no circumstances in which it makes sense to treat the slot name argument as a variable, because slot tags are parsed in their entirety at template compilation time (whereas variables are resolved at template render time). Quoted strings are required here merely for the sake of consistency.

My personal thoughts on this are that I prefer the previous approach of treating names as literal identifiers. I don't see myself using dynamically specified components or fill tags any time soon, and my own style is to use valid_python_identifiers for names anyway. But at the same time, I see this as an all-or-nothing thing. I can happily live with quoting names so that others may have their dynamism. What would make me sad is having a different set of rules for each tag type.

Regarding your second point, about repeating the slot/fill name in the end* tag, that should work as-is. Are you saying it doesn't at the moment?

[timothyis]

Ah yes indeed, it works! I've no idea why I got an error trying that before, apologies! Thanks for the response. The refactor is done and now we're on the latest 👍🏼