[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)
PR Type
What kind of change does this PR introduce?
[ ] Bugfix
[x] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Other... Please describe:
Which package are you modifying?
[x] accordion
[ ] alert
[ ] alert-dialog
[ ] aspect-ratio
[ ] avatar
[ ] badge
[ ] button
[ ] calendar
[ ] card
[ ] checkbox
[ ] collapsible
[ ] combobox
[ ] command
[ ] context-menu
[ ] data-table
[ ] date-picker
[ ] dialog
[ ] dropdown-menu
[ ] hover-card
[ ] input
[ ] label
[ ] menubar
[ ] navigation-menu
[ ] pagination
[ ] popover
[ ] progress
[ ] radio-group
[ ] scroll-area
[ ] select
[ ] separator
[ ] sheet
[ ] skeleton
[ ] slider
[ ] switch
[ ] table
[ ] tabs
[ ] textarea
[ ] toast
[ ] toggle
[ ] tooltip
[ ] typography
What is the current behavior?
I'm building an expandable menu for (nested) router links in my app and need the ability to set the state of a particular accordion item through an Angular input, which currently isn't possible.
This change moves the state handling responsibility down to the individual items and the parent is only informed through signal emissions about which item is open/closed.
Does this PR introduce a breaking change?
[ ] Yes
[x] No
Other information
Coming from a pure rxjs background I'm only starting to learn how to work with Signals, and definitely still struggle.
I was gonna use an input signal for the state on the item, but it seems there is no way of programmatically manipulating it so I had to resort to making it a signal to be able to call set on it from the component.
For the ContentChildren part I saw that the latest Angular version has a contentChildren signal, which I wanted to use, but turns out we're not updated yet.
I wanted the openItemIds to be a computed signal based on all accordion item states, but when I tried that the signal was not recomputed if any of the inner state signals emitted.
My guess is that the computed signal only works with "top-level" signals, and any signal (in a .map for example) does not retrigger a recompute.
Would appreciate any suggestions on how to write this cleaner.
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
Which package are you modifying?
What is the current behavior?
I'm building an expandable menu for (nested) router links in my app and need the ability to set the state of a particular accordion item through an Angular input, which currently isn't possible.
This change moves the
statehandling responsibility down to the individual items and the parent is only informed through signal emissions about which item is open/closed.Does this PR introduce a breaking change?
Other information
Coming from a pure rxjs background I'm only starting to learn how to work with Signals, and definitely still struggle.
I was gonna use an
inputsignal for the state on the item, but it seems there is no way of programmatically manipulating it so I had to resort to making it a signal to be able to callseton it from the component.For the
ContentChildrenpart I saw that the latest Angular version has acontentChildrensignal, which I wanted to use, but turns out we're not updated yet.I wanted the
openItemIdsto be a computed signal based on all accordion item states, but when I tried that the signal was not recomputed if any of the innerstatesignals emitted. My guess is that the computed signal only works with "top-level" signals, and any signal (in a.mapfor example) does not retrigger a recompute.Would appreciate any suggestions on how to write this cleaner.