Repeat section's remove button is never disabled: ngFor shadows the field it reads
- Dominant language
- Scala
- Stars
- 314
- Forks
- 187
- Avg merge
- 1d 21h
- Merged PRs (30d)
- 214
Description
### What happened?
In `repeat-dnd.component.html` the per-row remove button is meant to be disabled when the field is read-only, but the guard never takes effect: the `*ngFor` shadows the name it reads.
```html
...
```
Inside the loop, `field` is the loop variable — one entry of `field.fieldGroup` — not the component's own `field`. Sub-fields carry no `templateOptions.disabled`, so the expression is always `undefined` and the button is never disabled.
The add button, which sits **outside** the loop, reads the same expression correctly and does disable.
### How to reproduce?
Render `FormlyRepeatDndComponent` with `field.templateOptions.disabled = true` and inspect the two buttons:
| Button | In the `*ngFor`? | Rendered |
|---|---|---|
| add | no | `disabled="true"` |
| remove (each row) | yes | no `disabled` attribute |
Confirmed in a spec run against `main`: the add button renders `disabled="true"` while the remove buttons render no disabled attribute at all with the identical binding.
### Version/Branch
1.3.0-incubating-SNAPSHOT (main)
### Expected behavior
A read-only repeat section should not offer per-row removal. Both buttons should be disabled together.
### Suggested fix
Rename the loop variable so it stops shadowing, e.g.:
```html
```
and leave the `[disabled]="field.templateOptions?.disabled"` bindings pointing at the section's field. The inner `formly-field` binding would become `[field]="subField"` off `row.fieldGroup` accordingly.
### Additional context
Found while adding rendering tests for this component (the spec previously exercised only `onDrop` and never rendered). Those tests deliberately assert the add button's gating and **not** the remove buttons', so that the current behaviour is not cemented before this is fixed.
Contributor guide
Assessment
This issue has not been assessed yet.