Support disabling individual radios without disabling control

<input type="radio" name="food" ngModel disabled>
<input type="radio" name="food" ngModel>

Must wait for a minor release to make API changes.

fix(forms): disable all radios with disable()

Is this fixed yet?
Because when i use reactive forms with radio buttons i can't seem to
be able to disable individual radio buttons in my template using the [disabled]="expression"
attribute.

Disabling the entire control seems to work fine however.

Here's a workaround: set the attribute instead of the property, keeping in mind that the values that can be used to toggle the presence of the attribute are null and anything other than null.

For example:

[attr.disabled]="expression that evaluates to null or anything other than null"

Good Day. Any progress on this???

Still nothing in v5 about this issue ? 😖

Strangely it works if you put the disabled directive on the last radio.
Here is a plunker updated : https://plnkr.co/edit/B50csoS1S1U4TJG1L8gQ?p=preview

You can either set a different name for each radio but it's not w3c compliant...

The [attr.disabled] would work with native html elements such as inputs.

What if I have a custom ControlValueAccessor component that act as radio?

@Input()
disabled;  // Won't get the value from [attr.disabled]

For now my workaround has been the following:

   @Input()
   disabled;  // Won't get the value from [attr.disabled]

  @Input()
  set inactive(value) { this.disabled = value; }
  get inactive() { return this.disabled;}

So that I can set my component attribute like this:

<radio-button formControlName="fieldName" value="A">
<radio-button formControlName="fieldName" value="B" [inactive]="true">
<radio-button formControlName="fieldName" value="C">

The bug and all workaround I found
https://stackblitz.com/edit/angular-radio-bug

Can we now disable individual radio button of a radio button group (same formControlName) ?
any progress on v9.x?

Is this issue resolved in the latest version? Or is it still Open?

Looks to me like this still bites in Angular 12.

It seems that this wasn't fixed in Angular 14 either.

For me, the workaround using [attr.disabled] has stopped working in Angular 15.

The workaround setting [attr.disabled] has stopped working for us after upgrading to Angular 15 as well. We tried a few things:

if you set the [attr.disabled] value in ngAfterViewInit, it will disable the option as before (must be afterViewInit, won't work for onInit)
however, we tested several things and can be sure it's not a change detection related issue
- tried to call changeDetectorRef.detectChanges in ngAfterViewInit
- tried to get a reference of the option, and set this.inputOption.disabled = true
- tried to set disabled through renderer: this.renderer.setAttribute(this.inputOption, 'disabled', 'true')

Use a fieldset!

A workaround for Angular 15 I found on Stack Overflow

        <fieldset [attr.disabled]="option.isAvailable === false ? true : null">
          <input
            [id]="'radio-' + option.id"
            class="hover:cursor-pointer"
            type="radio"
            [value]="option.id"
            formControlName="selectedOptionId"
          />
        </fieldset>

Stack Overflow Issue

I don't like the field set workaround because it's not semantic. <fieldest> should be a grouping of all related input's, like a group of radio buttons. It should not be used just to make disable work.

Instead I came up with this:

export class InputRadioButton implements AfterViewChecked {
  @Input() isDisabled?: boolean;
  @ViewChild('inputEl') inputEl!: ElementRef;
  ...

  ngAfterViewChecked() {
    if (this.isDisabled) {
      this.inputEl.nativeElement.setAttribute('disabled', '');
    } else {
      this.inputEl.nativeElement.removeAttribute('disabled');
    }
  }
}

<input
  #inputEl
  type="radio"
  ...
/>

Note this works well with the keyboard. The entire field set is still focusable using tabs, and arrow keys still work to select individual radio buttons, skipping over the disabled ones

@SamuelMaddox

@SamuelMaddox You are absolutely right, your solution seems to make much more sense! 👍

Well angular team, are we going to get a standard way of implementing this fairly basic, important behavior in v18?

I think even one of these minimal solutions would be helpful:

Endorse/suggest the [attr.disabled]="expression ? true : null" or directive approach in the documentation so users don't need to search through bug reports and feature requests.
Remove the warning about [disabled] on a reactive radio input.

Angular allows select options to be disabled individually while sharing a single formControl. Why not radios?

Using Angular 17 and I can disable the entire button group, but not an individual button. It would be nice to be able to pick and choose.

I have a custom component implementing ControlValueAccessor that wraps around native <input type="radio" /> so that I can provide more custom design, which is a common task. Radio buttons of a group work with same formControl instance with the way things are implemented in my case. The inner <input type="radio" /> does NOT get its ControlValueAccessor cause I don't provide it with one.

I let my custom component have 'disabled' Input and I do document that when this input is disable=true then that takes precedence over the status of the form control (that it gets provided through [formControl], [formControlName], etc...), otherwise form control status is the one in effect. This works just fine for selectively disabling single radio buttons on per-case basis, yet, I get the warning from

angular/packages/forms/src/directives/reactive_directives/form_control_directive.ts

Line 94 in 55e3a3a

set isDisabled(isDisabled: boolean) {

of

It looks like you're using the disabled attribute with a reactive form directive. If you set disabled to true
when you set up this control in your component class, the disabled attribute will actually be set in the DOM for
you. We recommend using this approach to avoid 'changed after checked' errors.

But thats not true, because that effect happens only for ControlValueAccessors that are implement in Angular such as RadioControlValueAccessor, see

angular/packages/forms/src/directives/radio_control_value_accessor.ts

Line 244 in 55e3a3a

this.setProperty('disabled', isDisabled);

.

But thats not the accessor I am using anywhere in my code, so this warning still shows up, even though its not related to my usecase, where the behavior is well documented.

So now I have to:

Be stuck with the warning, even though its unrelated to my code
Use a different name other than "disabled"

Could the warning be shifted to the subclasses of BuiltInControlValueAccessor that actually do the disabled prop writing behavior instead?

EDIT: opened separate issue #57793

@JeanMeche

@JeanMeche this can be closed. It is a structural limitation that the code documents: reactive forms model a whole radio group as one FormControl, so there is no per-radio state to set. The comment in RadioControlValueAccessor says exactly this, and it is also why the setDisabledState special case for radios exists.

Supporting it means giving each radio its own state, which is a redesign of how radio groups map to controls, not an incremental change. Needs Design since 2016 with no movement.

In the meantime [attr.disabled] on the individual input still works, which is what that special case preserves. Related: #53240.

Navigation Menu

Repository navigation

Support disabling individual radios without disabling control #11763

Use a fieldset!

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Support disabling individual radios without disabling control #11763

Description

Activity

S1ri0S commented on Oct 17, 2016

knowledge2thepeople commented on Dec 21, 2016

AlexKhymenko commented on Aug 7, 2017

maximelafarie commented on Nov 12, 2017

clementgpro commented on Apr 16, 2018

FortinFred commented on Sep 7, 2018

Et3rnal commented on May 29, 2019

naingaungphyo commented on Apr 3, 2020

aphilip66 commented on May 31, 2021

hoclun-rigsep commented on Oct 4, 2021

maks-humeniuk commented on Jun 24, 2022

wipascal commented on Dec 13, 2022

angelaman commented on Feb 3, 2023

sevspo commented on Feb 8, 2023

Use a fieldset!

SamuelMaddox commented on May 11, 2023

sevspo commented on May 22, 2023

maurice-does-software commented on Jan 22, 2024

commadelimited commented on Aug 13, 2024

Erbenos commented on Sep 12, 2024

arturovt commented on Sep 29, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions