Igniteui-angular: Build fails in "strictTemplates" mode for <igx-column [dataType]="'number'">

[catull]

Description

Setting this in tsconfig.json

{
  "angularCompilerOptions": {
    "enableIvy": true,
    "fullTemplateTypeCheck": true,
    "preserveWhitespaces": false,
    "strictInjectionParameters": true,
    "strictTemplates": true
  },
 .......
}

causes a build error for

<igx-column [header]="'Total'" [field]="'total'" [filterable]="true" [dataType]="'number'"> </igx-column>

Setting "strictTemplates": false avoids the build failure described above.

• igniteui-angular version: 9.0.0-rc.2
• browser: build issue

Steps to reproduce

1. Try with "strictTemplates": true
2. Experience the error
3. Try with "strictTemplates": false
4. The build does not stumble.

Result

Build failure

src/app/pages/home/statistics/statistics-monthly.component.html:13:88 - error TS2322: Type '"number"' is not assignable to type 'DataType'.

13       <igx-column [header]="'Total'" [field]="'total'" [filterable]="true" [dataType]="'number'"> </igx-column>

Expected result

Strict template mode should be possible.

[github-actions[bot]]

There has been no recent activity and this issue has been marked inactive.

[catull]

Any news here ?
I'd like to switch on stricter mode, but this bug prevents me from doing so.

[catull]

This is still the case in Angular 9.1 and Angular 10.

[damyanpetev]

Alright, so the basic issue is that in TypeScript enums with string values will not accept the string value itself (unlike numbers).

I've looked at issues like https://github.com/Microsoft/TypeScript/issues/14352 and one option is to union type our enum inputs with string, but I'm not super fond of the idea because it looses the fixed set of values the enum gives us.
Also, from what I see in https://github.com/microsoft/TypeScript/issues/17690#issuecomment-321319291 the behavior is by design - i.e. only the enum itself should be used, not the underlying value (which is considered hidden and subject to changes) and that makes a lot of sense actually.

Because it's incredibly clunky to use the actual enum in the template (must be assigned to component property) we're not the only ones facing this issue - https://github.com/angular/angular/issues/35363, and at least for now it doesn't seem like much can can/will be done in this direction.

In essence - we should be using full union types on all string @Input properties. To maintain backwards compatibility, we can keep existing enums as exported constants (see below), so Enum.Prop continues to work in existing apps.

This solution came from one of the above issues to a way to create "enums" before they were introduced in TypeScript:
https://github.com/microsoft/TypeScript/issues/3192#issuecomment-261720275

Here's an example TypeScript Playground so you can get a feel how this behaves. The role of the mkenum function is to force the string value type to use the specific string itself - so North: "N" instead of North: string. Those are also critical for the next step that extract them from the constant's type to create the string union.

In our case, for example the enum:

export enum DataType {
    String = 'string',
    Number = 'number',
    Boolean = 'boolean',
    Date = 'date'
}
// in IgxColumnComponent:
@Input()
    public dataType: DataType = DataType.String;

becomes:

export const DataType = mkenum({
    String: 'string',
    Number: 'number',
    Boolean: 'boolean',
    Date: 'date'
});
export type DataType = (typeof DataType)[keyof typeof DataType];

(as of recent - I think Typescript 3.8-9) types can also be exported so the single import gives you both:

and the property code (and client apps for that matter) can continue using the "enums" as before, except they don't have to.

@rkaraivanov Thoughts?

Keep in mind this should only be applied to enums with string values used on @Input properties. The ones under complex objects not meant for the template (like some direction in the overlay settings is probably fine). Also be mindful of the types - last time I checked a type definition becomes type declare in d.ts and that's global. I'm hoping the export will help, but haven't tested. So do check we're not polluting the global namespace with types and if we can't avoid - make sure those are prefixed (not like DataType..)

[rkaraivanov]

@damyanpetev
This looks good enough for me, given the option to have some backwards compatibility with the existing string enumerations and convenient enough for users of the product. As you've mentioned this will target only public string enumerations and hopefully future development will rely on string unions instead of string enumerations.

[kdinev]

@mmart1n Please pull this in 9.1.x. 10.0.x is out of maintenance,