Import#
import { CngxTimelineItemTpl } from '@cngx/common/timeline'
Description#
The row template. The one slot with no built-in fallback: only the consumer knows what an event of theirs looks like.
Bind the same array the timeline gets and the let- variables come out
typed - [cngxTimelineItem] exists to pin T, nothing more:
<cngx-timeline [items]="events()" [dateAccessor]="at">
<ng-template [cngxTimelineItem]="events()" let-event let-last="last">
<cngx-timeline-item [position]="last ? 'last' : 'middle'">
<cngx-time cngxTimelineTime [date]="event.at" />
<p>{{ event.summary }}</p>
</cngx-timeline-item>
</ng-template>
</cngx-timeline>Named CngxTimelineItemTpl so it does not collide with the
CngxTimelineItem component; the selector stays cngxTimelineItem,
which is what consumers write.
Metadata#
Index#
Inputs#
readonly T[] | undefined, readonly T[] | '' | undefinedType carrier, never read at runtime. Angular cannot infer a structural
directive's context generic from a sibling input on the host component,
so T has to be pinned on the directive itself; binding the same array
the timeline renders does that, and ngTemplateContextGuard below then
types every let- variable. This is NgForOf's ngForOf mechanism,
not a cngx invention.
Optional, and tolerant of the bare cngxTimelineItem attribute every
v1 consumer writes: an unbound attribute binds the empty string, which
strictTemplates would otherwise reject against an array type. The
empty string coerces to undefined and T falls back to unknown -
the Bridge-Input shape the library uses wherever an attribute doubles
as an opt-in.
Nothing enforces that the array bound here is the array bound to
[items]; a mismatch only mistypes the let- variables, which the
template type-checker then rejects at the use site.
undefined, { transform: (value) => (typeof value === 'string' ? undefined : value) }, Instance Properties#
Methods#
CngxTimelineItemContextngTemplateContextGuard(_dir: CngxTimelineItemTpl<T>, ctx: unknown)unknown