Seems like nested attrs not supported (with test case)

[mattbha]

This one has "got me" twice now. I'd expect attrs to be passed.

High level I reuse the <div class="... {{ class }}" {{ attrs }}> {{ slot }} </div> pattern all over.

    def test_basic_attrs(self):
        self.create_template(
            "cotton/dropdown.html",
            """
            <c-vars class />
            <select class="p-2 text-black w-full bg-white border border-black {{ class }}" {{ attrs }}>
                {{ slot }}
            </select>
            """,
        )

        self.create_template(
            "cotton/dropdown_city.html",
            """
                <c-dropdown {{ attrs }}>
                    <option value="SF">San Francisco</option>
                    <option value="NY">New York</option>
                </c-dropdown>
            """,
        )

        self.create_template(
            "nested_attrs_view.html",
            """
                <c-dropdown-city class="w-full" name="city-dropdown-2" />
            """,
            "view/",
            context={},
        )

        with self.settings(ROOT_URLCONF=self.url_conf()):
            response = self.client.get("/view/")
            self.assertNotContains(response, "<c-vars")
            self.assertNotContains(response, "{{ attrs }}")
            self.assertContains(response, 'name="city-dropdown-2"')
            self.assertContains(response, ' border-black w-full"')

            # printed
            # <select class="p-2 text-black w-full bg-white border border-black w-full" {{ attrs }}>
            #         <option value="SF">San Francisco</option>
            #         <option value="NY">New York</option>
            # </select>

            # expected
            # <select class="p-2 text-black w-full bg-white border border-black w-full" name="city-dropdown-2">
            #         <option value="SF">San Francisco</option>
            #         <option value="NY">New York</option>
            # </select>

[wrabit]

I can see the case for this, but we cannot really place {{ attrs }} onto a <c- due to limitations in compiled code.

But this could work: (I also like it as it feels a bit clearer about what’s going on)

<!-- cotton/dropdown_city.html -->

<c-dropdown :attrs="attrs">
    <option value="SF">San Francisco</option>
    <option value="NY">New York</option>
</c-dropdown>

(If we do this right now, we would get a key value pair like: attrs="class="w-full" name="city-dropdown-2"")

So the outlay of work looks like:

• Detect when we're passing an Attrs object
• Alter the attrs generation logic to combine any Attrs object that was passed in along with those explicitly itemised on the component

Optional extra:

• We may also want to merge class if there is one in the passed down attrs and one explicitly added.

[mattbha]

whats stopping <c-dropdown {{ attrs }}> getting sent to dropdown.html as <c-dropdown class="w-full" name="city-dropdown-2">?

---

<c-dropdown :attrs="attrs">

to this point, I think we are running into dangerous territory with attrs as its already a high mental load... but I think if we do this it should be :attrs=attrs or even just :attrs or some other way to indicate this (i prefer removing the quotes for :vars and im not sure :attrs= makes sense because what do we do if its something like :attrs=1,2,3)

my vote would be for :attrs alone to just "pass above attrs to child component'

[wrabit]

whats stopping <c-dropdown {{ attrs }}> getting sent to dropdown.html as ?

Because it compiles to {% c dropdown {{ attrs }} %} which is not supported by default in Django and since {{ attrs }} is a template variable, the compilation step is completely separate Django's parsing step.

I think :attrs=attrs as a first step, and then look at adding support in general for shorthand attributes, so any attribute and value could be passed in the same way <c-cart :user :products /> etc.

[mattbha]

I think :attrs=attrs as a first step, and then look at adding support in general for shorthand attributes, so any attribute and value could be passed in the same way etc.

this works for me, and is a good idea

[melotte25]

This would be great!

To help provide more justification and other use cases, being able to pass a FormField widget's attrs would be valuable too. With the above, I think it would work the same way, but would be great to put in documentation (or even have an example <c-django_form_input :field="form.expiration" /> where the component can then dynamically build out an appropriate <input> using all the Form widget data.

Example where this could be helpful:

class TestForm(forms.Form):
    expiration = forms.DateField(
        widget=forms.DateInput(
            attrs={
                'type': 'date',
                'min': timezone.now().date().isoformat(),
            },
            format='%Y-%m-%d',
        ),
        required=True,
        label='Expiration Date',
    )

[wrabit]

@melotte25 Proxying and passing {{ attrs }} dict now supported in 2.1.0