Share context from parent to child via slot?

[Dresdn]

I'm working with components that use {{ slot }} to render children, and I’ve run into a context propagation issue. Here's a simplified example:

cotton/parent.html

<div id="{{ id }}" class="parent" {{ attrs }}>
  {{ slot }}
</div>

cotton/child.html

<div data-id="{{ id }}" class="child" {{ attrs }}>
  {{ slot }}
</div>

app/view.html

<c-parent id="foo-id">
  <c-child>
    Some text
  </c-child>
</c-parent>

In the rendered output, {{ id }} inside child.html is empty:

<div id="foo-id" class="parent">
  <div data-id="" class="child">
    Some text
  </div>
</div>

One option I can do is wrap with {% with %}, but it's ugly:

{% with id="foo-id" %}
  <!-- The {{ id }} would actually live in parent.html in this case... -->
  <div id="{{ id }}" class="parent">
    <div data-id="" class="child">
      Some text
    </div>
  </div>
{% endwith %}

There's been some discussion around passing data, and while I was going to chime in, I think this ask is slightly different. Here's what I would consider related issues:

• Support passing down attrs #192
• Allow slots to have attributes #224

Is there a way to have parent attr / c-vars to pass into children components? I did try setting COTTON_ENABLE_CONTEXT_ISOLATION = False as a long shot, but saw the same results.

For extra context, we're trying to move components from Preline/Tailwind to Cotton, and their plugins use data-* attributes to "link" elements together (eg, a <button> opens a <modal>), so passing a selector down the stack would be extremely beneficial.

Thank you!

[SakariaNdadi]

Hi, This worked for me; in your child component attrs = {{ attrs }}.

…

On Thu, 27 Mar 2025 at 3:32 AM, Miguel ***@***.***> wrote: I'm working with components that use {{ slot }} to render children, and I’ve run into a context propagation issue. Here's a simplified example: cotton/parent.html <div id="{{ id }}" class="parent" {{ attrs }}> {{ slot }} </div> cotton/child.html <div data-id="{{ id }}" class="child" {{ attrs }}> {{ slot }} </div> app/view.html <c-parent id="foo-id"> <c-child> Some text </c-child> </c-parent> In the rendered output, {{ id }} inside child.html is empty: <div id="foo-id" class="parent"> <div data-id="" class="child"> Some text </div></div> One option I can do is wrap with {% with %}, but it's ugly: {% with id="foo-id" %} <!-- The {{ id }} would actually live in parent.html in this case... --> <div id="{{ id }}" class="parent"> <div data-id="" class="child"> Some text </div> </div>{% endwith %} There's been some discussion around passing data, and while I was going to chime in, I think this ask is *slightly* different. Here's what I would consider related issues: - #192 <#192> - #224 <#224> Is there a way to have parent attr / c-vars to pass into children components? I did try setting COTTON_ENABLE_CONTEXT_ISOLATION = False as a long shot, but saw the same results. For extra content, we're trying to move components from Preline/Tailwind to Cotton, and their plugins use data-* attributes to "link" elements together (eg, a <button> opens a <modal>), so passing a selector down the stack would be extremely beneficial. Thank you! — Reply to this email directly, view it on GitHub <#272>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AX4PGOCU5QEUMXQ4U6FFUR32WNIJNAVCNFSM6AAAAABZ3XOO6KVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZYGEZTIMJRGI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Dresdn]

Hi @SakariaNdadi,

Thank you for the response. I spent more time than I'd like to admit trying to in your child component attrs = {{ attrs }} without luck.

Can you share more context? The only thing that's made sense to me is to change child.html to:

<div attrs="{{ attrs }}" data-id="{{ id }}" class="child" {{ attrs }}>
  {{ slot }}
</div>

but that renders:

<div id="foo-id" class="parent">
  <div attrs="" data-id="" class="child">
    Some text
  </div>
</div>

[wrabit]

Released in 2.1.0

[maximbelyayev]

@wrabit I can definitely appreciate the concern behind unintended coupling as I imagine it (data flow, structural concerns, inheritance/overwriting/collision concerns in context/props/contracts ??).

It goes both ways; currently the solution with field.html you provided also tightly couples attr proxying to component anatomy. I.e., what if users want to define <c-field.label> after <c-input> instead of before, or they want wrap one of the children? That type of behavior could theoretically be accomplished via props and if/else blocks, but would become unfriendly and difficult to understand as more complex components are encountered. As a lazy person, I'd also just like to avoid defining the : proxy on every child/descendant... :)

I'm essentially describing an ideal state, where the option exists for attr proxing to go through a single {{ slot }} via the parent. That way users have the flexibility to define the anatomy of descendant components however they want, while still being able to reference some attrs or shared state.

I fully understand if this ideal state is unachievable right now, and/or would require some additional feature or special handling to be introduced to cotton. I hope to at least spark the conversation if anyone sees value in it, or becomes in-demand. I'm willing to help and contribute in the future if so! Thanks again.

[wrabit]

what if users want to define <c-field.label> after instead of before

If you are building a framework, it's expected to contain an opinion and could give option to place labels in sensible places, therefore you might consider adding options like label-last - the rigidity here would probably help the developer instead of giving complete freedom - also there is a question of reliably supporting such freedom without breaking a system. These are all subjective points though.

Would a {{ parent }} solve it? Like {{ parent.field.[..] }}?

[SamuelJennings]

Here's a relatively simple proposal that would allow alpine.js-like scoping. More of a thought experiment so I didn't test it or anything.

# After _extract_vars_from_template (line ~92, templatetags/_component.py)

# Get parent's already-merged scope from stack (if exists)
parent_scope = cotton_data["stack"][-2]["scope"] if len(cotton_data["stack"]) > 1 else {}

# Merge parent scope and store on stack for children to inherit
component_data["scope"] = {
    **parent_scope,  # All ancestor values (already cascaded)
    **vars,            # This component's c-vars (can override parents)
    **component_data["slots"],  # Named slots from this component
    **component_data["attrs"].make_attrs_accessible(),  # This component's attrs (highest priority)
}

# Full rendering state (inheritable context + special objects)
component_state = {
    **component_data["scope"],  # All inheritable values (ancestors + current)
    "attrs": component_data["attrs"],  # Special Attrs object
    "slot": default_slot,  # Default slot content
    "cotton_data": cotton_data,  # Cotton internal data
}

This would result in the following scenario:

Components

cotton/container.html

<c-vars border="solid" />
<div class="container border-{{ border }}">
  {{ slot }}
</div>

cotton/card.html

<div class="card border-{{ border }}">
  <h3>{{ title }}</h3>
  {{ slot }}
</div>

Usage Example

<c-container border="dashed">
  
  <c-card title="First Card">
    <!-- border = "dashed" (inherited from container) -->
    <!-- title = "First Card" (own attr) -->
    Content here
  </c-card>
  
  <c-card title="Second Card" border="dotted">
    <!-- border = "dotted" (OVERRIDES container's "dashed") -->
    <!-- title = "Second Card" (own attr) -->
    More content
  </c-card>
  
  <c-card title="Third Card">
    <!-- border = "dashed" (inherited from container) -->
    <!-- title = "Third Card" (own attr) -->
    Final content
  </c-card>
  
</c-container>

Rendered Output

<div class="container border-dashed">
  
  <div class="card border-dashed">
    <h3>First Card</h3>
    Content here
  </div>
  
  <div class="card border-dotted">
    <h3>Second Card</h3>
    More content
  </div>
  
  <div class="card border-dashed">
    <h3>Third Card</h3>
    Final content
  </div>
  
</div>

Pros:

• DRY - Define once, cascade down
• Better ergonomics - Less boilerplate for compound components
• Aligns with alternative component building libraries (e.g. Alpine.js)
• Flexible - Children can still override parent values
• Cleaner templates - Especially for deep component hierarchies
• Does not effect COTTON_ENABLE_CONTEXT_ISOLATION or only

Cons:

• Implicit behavior: "Where did this variable come from?" harder to answer/debug
• Naming collisions: Parent and child use same var name unintentionally

Potential opt-in?

To avoid some of the cons, we could make the scoped behavior opt-in using either a settings variable or a reserved attribute (scoped ) that tells a component to pass on it's current scope to children. E.g. <c-accordion scoped id="myAccordion">

[zadiq]

I think a merge of both ideas would be ideal. Using parent makes it apparent and explicit where a variable might be coming from. Subsequently, a child could rely on the parent's value as a fallback: "{{ id || parent.id }}".

I also agree with the idea of using scope to explicitly declare the behaviour. An exception to this could be maybe allowing the behaviour in nested components implicitly. E.g. c-accordion.item would automatically have access to c-accordion as parent in:

<c-accordion>
   <c-accordion.item>...</c-accordion.item>
   <c-accordion.item>...</c-accordion.item>
</c-accordion>

The expectation is that nested components are always tightly coupled.

Lol, not to complicate things further, parent could be nested as well: parent.parent...

Finally, just to add to the argument for this feature is that in UI components libraries that are primarily CSS-based (little to no JS), they rely on cross-referencing id and other HTML attributes between different parts for interactive components like tabs, accordions, drawers, and so on.

I am happy to support with the implementation of this feature if needed.

[SamuelJennings]

Alternate, less intrusive proposal

This builds a bit off the idea of providing a parent to the context. My opinion is that providing only parent to the context is a bit limited. Therefore, I propose the following:

1. Store scope on the stack

Similar to my previous suggestion but NO merging of context from parent to child.

component_data["scope"] = {
    **vars,          # This component's c-vars
    **component_data["slots"],
    **component_data["attrs"].make_attrs_accessible(),
}

2. Create new ComponentStack class

This class would wrap the existing stack list and provide an API for interacting with it. E.g. retrieving components by name or conceptual relationship:

class ComponentStack:
    def __init__(self, stack_list):
        self._stack = stack_list

    def __getattr__(self, name):
        # Find closest ancestor component by name
        for component in reversed(self._stack):
            if component.get("key") == name:
                return StackComponent(component)
        return StackComponent({})

    # Optional helper methods for common access patterns
    def parent(self):
        # Immediate parent
        if len(self._stack) >= 2:
            return StackComponent(self._stack[-2])
        return StackComponent({})

class StackComponent:
    def __init__(self, component_data):
        self._data = component_data

    def __getattr__(self, name):
        # Direct access to scope values
        return self._data.get("scope", {}).get(name)

3. Inject the stack object into context

component_state = {
    **component_data["scope"],
    "attrs": component_data["attrs"],
    "slot": default_slot,
    "stack": ComponentStack(cotton_data["stack"]),  # NEW
    "cotton_data": cotton_data,
}

Usage Examples

Accordion

<!-- accordion/item.html -->
<div class="accordion-item" data-target="{{ stack.parent.id }}">
  {{ slot }}
</div>

OR, for deeper nested components, we specify the target component by name (if it has a key in the stack):

<!-- accordion/item.html -->
<div class="accordion-item" data-target="{{ stack.accordion.id }}">
  {{ slot }}
</div>

Template API

{{ stack.accordion.id }}        <!-- Find ancestor by name -->
{{ stack.parent.id }}        <!-- Immediate parent -->
{{ stack.root.whatever }}       <!-- Topmost component? -->

Pros

• Does not pollute context namespace
• Aligns with Cotton philosophy - Maintains explicit over implicit behaviour
• Purely additive, existing code works unchanged
• Easy to trace variable sources up the component tree
• Predictable behaviour without hidden context merging
• Wrapper class suitable for progressive enhancement. Start simple, add more functionality later

Edit

On second thought, I don't think it would be this simple. The "find ancestor by name" API would likely fail with more complex component names. Such an API would probably require a template tag/filter.