Enterprise-ng: Soho Input cannot be disabled using FormGroup

Created on 6 Jun 2018  路  6Comments  路  Source: infor-design/enterprise-ng

Steps to reproduce:

  • Have Component with template with input <input formControlName="count" soho-input>
  • Use following body of component .ts
formGroup: FormGroup;
model: {
    count: number
  } = {
    count: 10
  };

  constructor(private formBuilder: FormBuilder) {
    this.formGroup = this.createForm();
    this.formGroup.disable();
  }

  private createForm() {
    return this.formBuilder.group({
      count: [this.model.count]
    });
  }

Expected result:
input component is disabled

Actual result:
input component is enabled

Guidelines:
got from channel chat - can help
The hook between an angular component and the jQuery widget does not handle disable requests. Specifically, the components needs to override the following ControlValueAccessor method:

/**
 * This function is called when the control status changes to or from "DISABLED".
 * Depending on the value, it will enable or disable the appropriate DOM element.
 *
 * @param isDisabled
 */
 setDisabledState(isDisabled: boolean): void {
   // NOP
 }
type

Most helpful comment

I have a fix for this on my fork, however all other controls that implement the ControlValueAccessor need to be updated so will take a little longer.

All 6 comments

The following code fixes soho-input.component.ts:

````typescript
@HostBinding('attr.disabled')
@Input()
isDisabled = undefined;

...

setDisabledState(isDisabled: boolean): void {
this.isDisabled = isDisabled ? true : undefined;
}

I have a fix for this on my fork, however all other controls that implement the ControlValueAccessor need to be updated so will take a little longer.

The change associated with this fix requires some changes to the existing components. For example:

<input soho-radiobutton type="radio" >
and
@HostBinding('attr.disabled') @Input() disabled: boolean.

The problem is that the ControlValueAccessor and the disabled attribute is competing with each other, resulting in the form not always being configured correctly.

I propose removing these attributes (which would be a breaking change) requiring apps to use [attr.disabled] or a form and model. I could leave the 'disabled' property but mark it as deprecated (in the log) - however it would need to lose the @HostBinding.

Any comments: @tmcconechy @fitzorama @pwpatton @krishollenbeck

This seems ok to me if noted in the changelog.

@tmcconechy do we assign these for QA?

We dont have a way for functional QA to QA any of the angular stuff at the moment. QA is crowd sourced among our teams for this part. But working on that. So just close the issue for now.

Was this page helpful?
0 / 5 - 0 ratings