Chips Autocomplete cant be disabled (both input and chips)

[cnotv]

trafficstars

Bug, feature request, or proposal:

Bug

What is the expected behavior?

Setting control to disabled should disable both input and chips.

What is the current behavior?

Nothing changes even if the formControl is set to disabled.

What are the steps to reproduce?

Open the pen ad try to toggle the disable status, you'll get a boolean value in the log.

• Pen created using markup from the documentation
• Chip with autocomplete Doc Pen
• Autocomplete with disable toggle Doc Pen

What is the use-case or motivation for changing an existing behavior?

Every provided input from the library must have a disabled case.

Which versions of Angular, Material, OS, TypeScript, browsers are affected?

Same version as documentation. 7.0.3/7.0.2

Is there anything else we should know?

The component should propagate the disable status to the chips, using existing API, and dropdown as restriction set by Angular library.

[ethanzxlee]

Hi, is anyone working on this? I am thinking to take on this as my first contribution. 😀

[jelbourn]

Feel free to send a PR!

[ethanzxlee]

Should we put a formControl at the input? Shouldn't it be set at mat-chip-list level?

[jelbourn]

@zxlee618 I don't quite understand your question

[ethanzxlee]

So the code from Stackblitz is basically like this:

<mat-form-field>
  <mat-chip-list>
    <mat-chip></mat-chip>
    <input  [formControl]="fruitCtrl"/>
  </mat-chip-list>
</mat-form-field>

I am was saying that we should put the formControl at the mat-chip-list like this:

<mat-form-field>
  <mat-chip-list [formControl]="fruitCtrl">
    <mat-chip></mat-chip>
    <input/>
  </mat-chip-list>
</mat-form-field>

This would actually disable the input and autocomplete when the fruitCtrl is disabled. (with the current build)

However, there is different bug that I can see, the remove button on the chip won't be disabled in this case.

[jelbourn]

I'm not sure we'd want to encourage making the chip-list a form control. While it's currently implemented as role="listbox", we have an item in our backlog to change it to role="grid", which isn't a form control.

[ethanzxlee]

Hmm.. well MatChipList implements MatFormFieldControl at the moment. Sound like we might need to redesign the whole thing?

[jelbourn]

Yeah, that seems like something we'd have to work into the switch over to role="grid"

[ethanzxlee]

Ok, do we have any idea or suggestion for this to be done?

[jelbourn]

Having the chip-list be aware of the form control on its associated input is an area to explore

[Aleksandyr]

Hello @jelbourn I have a fix for the issue, but firstly we have to clarify a few things. As I observed in the API documentation you don't have exposed that MatChipList has a disabled input property which disables all chips that the list contains. So the questions here is do we need to keep that input setter or we can remove it?

Second one is: You have specified above in the conversation: I'm not sure we'd want to encourage making the chip-list a form control. While it's currently implemented as role="listbox", we have an item in our backlog to change it to role="grid", which isn't a form control. This means that here there is no need for that clause:

this.ngControl ? !!this.ngControl.disabled

Which leads to the other question: Do we need to implement here ControlValueAccessor interface at all?

The last question is: If we won't need disabled input property into MatChipList. We won't need this clause here at all.

(this._chipList && this._chipList.disabled);

After we clear all uncertainties I would be able to provide a fix for the issue.

[Rlcolli4]

Is there any update on this issue? We are using MatChipList in our form as well with the input as a form control. We have to set the disabled property manually because the input ignores the formControls enabled/disabled properties. As a result we get this warning, we would like to get rid of it but it looks like until this stuff is changed we won't be able to get rid of it: 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

[vishnu-dev]

@jelbourn Will we get any updates on this?

[ianmantripp]

I'm late to the party but as this is still "open", I'll post my working code.

I have a component (AutoChipsComponent) which is basically the same as the example with a few changes. In my application I have a whole bunch of instances of this component which are enabled/disabled depending on the values of other instances. I add a "disabled" input to the mat-chip-list:

auto-chips.component.html

<mat-form-field fxFlex (focusout)="focusOut($event)">
  <mat-chip-list #chipList [disabled]="disabled">
    <mat-chip
      class="my-chip"
      *ngFor="let item of selectedItems"
      ...

auto-chips.component.ts

@Input() disabled: boolean;

In the parent component one instance is: module-edit.component.html

<app-auto-chips
  #shoptypesSelector
  placeholder="Select Shoptype(s)"
  [items]=shoptypes
  [controller]=shoptypesCtrl
  [disabled]=true
>
</app-auto-chips>

and module-edit.component.ts

 @ViewChild('shoptypesSelector') shoptypesSelector: AutoChipsComponent;
...
setDisabled(state: boolean) {
    this.shoptypesSelector.disabled = state;
    this.profilesSelector.disabled = state;
  }

This works as expected, so in this example the status of "Shoptype" and "Profile" depend on the presence of "Sales" in "Departments".

[ankurdeal]

Is there any plan for this?

[Krun-al]

input tag within mat chip do this add -> mat-chip-list(#chipList="", [disabled]="condition") update -> matInput to matChipInput

This one worked for me

[zarend]

This issue has been fixed in the newer, MDC-based components. Install v15 to get access to them.

MatChipGrid has an @Input disabled, which allows the developer to disable the entire input and associated chips.

[angular-automatic-lock-bot[bot]]

This issue has been automatically locked due to inactivity. Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}