Complex primitives anatomy

[pimenovoleg]

@mrfrac and I have been analyzing the structure of components, and here's what we've observed.

When we talk about something being "easy", we mean it's clear, requires minimal adjustments, and is straightforward for developers to use.

We’ve identified two main scenarios:

1. Simple primitives like avatar, separator, etc., where we can easily use directives to implement the functionality.
2. Complex primitives like select, slider, radio, etc., where there are multiple child elements and significant logic between them.

For the second case, the approach used by @lskramarov in the Select component seems to work exceptionally well:

template: `
        <ng-content select="[rdxSelectTrigger]" />

        <ng-template
            (attach)="onAttached()"
            (detach)="onDetach()"
        >
            <ng-content select="[rdxSelectContent]" />
        </ng-template>
    `,

The ng-content mechanism is similar to slots in Web Components or children in React, but it offers more powerful customization capabilities through the select attribute.

Benefits:

• Explicit content separation.
  Clearly defines and separates different parts of the component's content.

• Flexibility and reusability
  Developers can provide custom elements for triggers ([rdxSelectTrigger]) and content ([rdxSelectContent]).

• Lifecycle management (enhanced with Signals API)
  Event handlers like (attach) and (detach) on the ng-template enable efficient state management, such as initialization or resource cleanup.

This is particularly useful for components that interact with overlays, portals, or dynamic DOM elements.

[pawel-twardziak]

Yes, I've seen and analized on select component - good job!
I tried to apply that approach to the popover but it appeard out of sudden that I need to refactor all the code to make it sensible.
So I switched back to the directive aproach.

I see that sometimes the component approach is better than the directive one and in another time it is the other way around. It depends :)

We could also expose the root of each funability as both, the component and the directive - like PrimeNG does.

In our select we have:

@Component({
    standalone: true,
    selector: '[rdxSelect]',
    template: `
        <ng-content select="[rdxSelectTrigger]" />

        <ng-template
            [cdkConnectedOverlayOpen]="open"
            [cdkConnectedOverlayOrigin]="elementRef"
            [cdkConnectedOverlayPositions]="positions"
            [cdkConnectedOverlayScrollStrategy]="overlay.scrollStrategies.reposition()"
            (attach)="onAttached()"
            (backdropClick)="close()"
            (detach)="onDetach()"
            cdkConnectedOverlay
        >
            <ng-content select="[rdxSelectContent]" />
        </ng-template>
    `
   // ...
})

So it works directive-like way but one downside is that that kind of selector cannot be applied to ng-template or ng-container so that we must use span for instance. Which is usually not the best way :)

Concluding, I reckon for the component approach it would be better to use standard selector like this:

@Component({
    standalone: true,
    selector: 'rdx-select',
    template: `
        <ng-content select="[rdxSelectTrigger]" />

        <ng-template
            [cdkConnectedOverlayOpen]="open"
            [cdkConnectedOverlayOrigin]="elementRef"
            [cdkConnectedOverlayPositions]="positions"
            [cdkConnectedOverlayScrollStrategy]="overlay.scrollStrategies.reposition()"
            (attach)="onAttached()"
            (backdropClick)="close()"
            (detach)="onDetach()"
            cdkConnectedOverlay
        >
            <ng-content select="[rdxSelectContent]" />
        </ng-template>
    `
   // ...
})

[pawel-twardziak]

Or we can create both: the base directive and the component extendind the drective with standard selector

[pawel-twardziak]

I would also unleash the directive composition of Angular - what I've done for one of the directives:

@Directive({
    selector: '[rdxPopoverTrigger]',
    standalone: true,
    hostDirectives: [CdkOverlayOrigin],
    host: {
        type: 'button',
        '[attr.id]': 'id()',
        '[attr.aria-haspopup]': '"dialog"',
        '[attr.aria-expanded]': 'popoverRoot.isOpen()',
        '[attr.aria-controls]': 'popoverId()',
        '[attr.data-state]': 'popoverRoot.state()',
        '(click)': 'onClick()'
    }
})

[pawel-twardziak]

However, there are quite a few ways to project content in Angular. ng-content is one of them ;)

[pimenovoleg]

It seems like there are no contradictions here 👍

My point is about having a root component that leverages content projection to better define and fix the anatomy. As you mentioned, this applies only to complex components. For simpler examples like the trigger, it doesn't make sense to replace it with a component. :)

In the final composition, I’d prefer developers to rely on components for clarity and consistency.
Example from a design system based on primitives:

Checkbox:

checkbox.component.ts
Usage: checkbox-02.ts

ooltip:

For the Tooltip, the usage of ng-template in the final implementation feels a bit clunky:
tooltip-02.ts

I believe this could be further refined for better developer experience.

@pawel-twardziak
UPD: Yep, its not good idea with Angular content projection for customize in project

[pimenovoleg]

I tried to apply that approach to the popover but it appeard out of sudden that I need to refactor all the code to make it sensible.

no need for refactoring:) Let's merge it as is.
After we’ll have time to test it in various use cases later and then draw conclusions for any potential adjustments.