Discussion: multiple instances of <c-vars />

[mattbha]

            <c-vars action />
            <c-vars class />

Seems the above is not supported, it's what I first naturally reached for -- I'd expect it to be the equivalent of

            <c-vars action class />

what do you think? in a more complex component I could see the use case of organizing c-vars

some_component.html

<c-vars name label_class />
<label name="{{ name }}" class="{{ label_class }}" />

<c-vars placeholder input_class />
<input placeholder="{{ placeholder }}" class="{{ input_class }}" {{ attrs }} />

[wrabit]

We technically could, but having c-vars declared at the top of each file provides some familiar place that we can quickly refer back to in order to check or debug a component behaviour. It acts as some kind of ruleset for the component, requiring users to acknowledge any defaults and changes to {{ attrs }} they should expect. I think allowing them to break out into different areas will make it more tricky to see the behaviour at a glance and easy to miss.

I don't think your example is to unwieldy to handle. But let's leave this open to see if anyone else wants to chime in here.

[mattbha]

I agree with "allowing them to break out into different areas will make it more tricky to see the behaviour at a glance and easy to miss."

however we already kind of break this model by not requiring everything to be in c-vars, and thus you are left parsing the template manually to grok all the variables used. without a c-strict option you can easily miss something since undefined vars dont raise an exception

[mattbha]

personally, I don't love c-vars at all. it seems its mainly to a) rip things out of attrs and b) provide defaults. to this point, a) I think we could detect variables used/consumed in the template and automatically remove them from attrs, and b) django provides a |default:0 tag natively. in theory with these 2 options we could remove c-vars entirely....

[wrabit]

Interesting observation, although:

1. You may be referring to a variable in outer scope, so they could be pulled from {{ attrs }} unintentionally.
2. I wouldn't be surprised if there was a use-case where you needed to reach for an item in {{ attrs }} and keep it in {{ attrs }}
3. You will lose out on dynamic default vars, also the ability to provide some sort of state to the component, for example
4. |default:0 doesn't allow you to pass string literals of basic python types (ok custom filter could exist, i.e. default_dynamic)

[wrabit]

But as for the justification of having it, all frameworks that have helped pioneer this way of building out UI's have this concept.

• Svelte with setting base level export let action = 'some default' and using $$restProps for fall through.
• Vue 3 defineProps or Vue 2 props then using $attrs in the template
• React with { action = 'some default', ...restProps }
• Laravel @props() + $attributes.

All allow you to set default, dynamic attributes and provide a fallthrough which exclude any that have been defined in the component.

[mattbha]

Interesting observation, although:

1. You may be referring to a variable in outer scope, so they could be pulled from {{ attrs }} unintentionally.

only would help protect this. and variables passed in as attrs should override outer scope imo.

2. I wouldn't be surprised if there was a use-case where you needed to reach for an item in {{ attrs }} and keep it in {{ attrs }}

sure, while rare, you could just add the attribute onto the tag manually

---

the div has name {{ name }}
<div name="{{ name }}" {{ attrs }}></div>

---

3. You will lose out on dynamic default vars, also the ability to provide some sort of state to the component, [for example](https://medium.com/@willabbott/django-cotton-component-variants-for-smarter-reusability-07d8e4358ed0)

this is true

however

<c-vars
  variant="info"
  :variants="{
    'info': 'bg-blue-100 border-blue-500 text-blue-700',
    'success': 'bg-green-100 border-green-500 text-green-700',
    'warning': 'bg-yellow-100 border-yellow-500 text-yellow-700',
    'error': 'bg-red-100 border-red-500 text-red-700'
  }"
  :icons="{
    'info': 'information-circle',
    'success': 'check-circle',
    'warning': 'exclamation',
    'error': 'x-circle'
  }"
/>

<div class="{{ variants|get_item:variant }} border-l-4 p-4 flex items-center space-x-4">
    <div class="flex-shrink-0">
        {% heroicon_outline icons|get_item:variant class="size-10" %}
    </div>
    <div>
        <div class="font-bold">{{ title }}</div>
        {{ slot }}
    </div>

this is terrible to me for many reasons I wont (but could) go into.

The way I prefer is just to break out into multiple alert components, so instead of

<c-alert type="info" title="Information">
    This is an informational message.
</c-alert>

<c-alert type="success">
...

youd just have <c-alert-info> and <c-alert-success>, both of which would utilize <c-alert>. this is how i actually do it in a project

alert.html

<div class="text-center text-white p-3 rounded-lg shadow m-2 {{ class }}">
    {{ slot }}
</div>

alert_success.html

<c-alert class="bg-green-500 font-semibold text-lg {{ class }}">
    {{ slot }}
</c-alert>

etc

4. `|default:0` doesn't allow you to pass string literals of basic python types (ok custom filter could exist, i.e. default_dynamic)

this is true. i do think the best case for c-vars is for default values -- so in theory we could greatly reduce c-var usage if there is no default value (by auto extracting from attrs). just an idea