ngx-sub-form: Disabled - is not included in formGroupValues

I ran into cases where I wish it was coming from getRawValue but value does reflect what formGroupe.value would return except that it’s recursive. Maybe we could add a formGroupRawValues 🤔

Any thoughts?

Yea, I think having a formGroupRawValues is the best outcome here, as it would be a breaking change otherwise and not really expected (we should be mirroring angular’s behavior where it isn’t broken)

I created a fix for that problem. Take a look at PR https://github.com/cloudnc/ngx-sub-form/pull/265.

The solution from daniel is a good working workaround. But I think its better to have this solved within the library and have a property to control whether the raw value or the value should emitted. In this case the users of the library have the option to control that.

But in common I agree it would be better to have a distinction between readonly and disable/enable solved by angular. But actually thats not the case, maybe angular will solve this in the future.

Hi!

Thanks for the nice library. It made my work simpler. I’ve dealt with this problem like this:

export abstract class SubFormComponentWithDisabledControls<A> extends NgxSubFormRemapComponent<A, A> {

protected abstract getDisabledControls(): (keyof A)[];

 writeValue(obj) {
   super.writeValue(obj);
   this.getDisabledControls().forEach(element => {
     this.formGroupControls[element].disable({emitEvent: false});
   });
 }

 protected transformToFormGroup(obj: A | null): A | null {
   return obj;
 }

 protected transformFromFormGroup(formValue: A): A | null {
   return this.formGroup.getRawValue();
 }
}

My solution may have caveats.

brainstorm sketch of how we could approach this https://www.typescriptlang.org/play/#code/MYGwhgzhAEBiD2AnAtgcUfArgB2gbwFgAoY6M6AcwFMAXaANzBEyoAoBKfU8nxWzRADsuRHmPKCkyJgDUmLAFzQA5ADN48Zd3EBfbdD0lR5ajQBKYAO5zmbToWPi+NAcIfjxklLPlUlajWUAGn0PaAATAEsIMAAjECpwm0UVWLBEYNDyQx5DYjyiYHhBCDpEK2SqaABeaABlAE9kWPgQVmVy619ldgBuYmJVTEFgGkji6EtESJoqStZVCiUEFHQsbHsBx2gikrpGEBroRYA6A5Z+ox4AeViAKypRk-CqVUjBKgAFDGwqRBoGqwDkFoJ1KiD3B4qIJMMg-nEEkpVEwIFQQtseFMZgi-McUWismRzrjTqYLF1bBx9Do+ltePwhAwmJcCkMRmMJmSKr4ADwAFQAfECmEowIIGuwlHyRPSXIyDgBtMG+AC6LK2u1KxykaxwRw+ljgOowOA4l2ImrouxoGBAlSOWNm83UqxNG3NhWKEFaVBOIHgFFY1ttlVpnpKPr9AdYXIpLCDxRtrVDYYtXsj-sDtweTwA1lQGhAE4Ik3bfOx2EA

☝️ I’ve gathered some of my thoughts on the issue linked above (CF comment).

Writing things down helped me clean up my mind and I don’t think that waiting for readonly attribute to be officially supported would be a good idea as this attribute doesn’t even work for some form elements anyway (like select, radio, range, etc).

So, sticking with disabled is probably the only way to go for now. Why? Because behind the scene ngx-sub-form uses ControlValueAccessor and the only hook available is setDisabledState. This is our only way to “broadcast” that down to sub forms.

Soooo. From here, I think our only choice is to have a DI token set at the form level that could be read by all the sub forms.

The external api may look like:

<my-root-form
  [myData]="data"
  (update)="update($event)"
  [disabled]="shouldBeDisabled"
  [disabledType]="DisabledType.DEFAULT"
></my-root-form>

Where DisabledType could be an enum:

export enum DisabledType {
  DEFAULT = 'Default',
  RAW_VALUE = 'RawValue',
}

Internally, the token may be:

export const DISABLED_TYPE_TOKEN = new InjectionToken<Observable<DisabledType>>(
  'DisabledTypeToken'
);

But would it be weird to have an Observable as a token? 🤔 Probably not.

The reason to have an observable here would be so that any time the disabledType input changes on the root form, we can update the root form plus all the sub forms.

Without an observable (or a way to update the sub forms at least), if you’re on a page looking at a resource where you should get the form value as DisabledType.DEFAULT then click on another resource, the component wouldn’t get destroyed but we’d still have to make sure the form value can change to DisabledType.RAW_VALUE for example.

Reporting back some information I discussed with @zakhenry to keep track of it there 😃

Forms in general (without Angular, frameworks, libraries or even JS) have 2 things available to make a form not editable:

• disabled attribute
• readonly attribute

They have different purpose so let me clarify:

• disabled
  • Impossible to edit
  • When using the tab key to navigate with the keyboard, all disabled fields will be skipped
  • When sending the form, all the disabled fields won’t be part of the data ⚠️
• readonly
  • Impossible to edit
  • When using the tab key to navigate with the keyboard, you’ll be able to navigate through the readonly fields
  • When sending the form, all the readonly fields will be part of the data

An interesting thread on Stackoverflow too for reference

As this is a browser behavior and not an Angular specific one, I think that by default ngx-sub-form should have the same behavior.

One possible way of dealing with that would be to provide a token and from that level, all the sub forms could return the raw value instead of the value. (if anyone has a better idea to deal with it please let me know).

BUT. I’m seriously questioning whether this is a good idea at all or not. It’s just going against a standard to avoid hiding part of the form (which we want to represent as “disabled”) and instead just displaying those values.

On the other hand, I can also see why this is really convenient to not rebuild a whole UI and just reuse the forms to display the values 🤷‍♂️

To anyone reading this, please do share your opinion on the topic 😸