When attempting to pass a numeric value to the @Input x property with two-way binding in Angular's strict template mode, an error is triggered

Question

When attempting to pass a numeric value to the @Input x property with two-way binding in Angular's strict template mode, an error is triggered

I am looking to enhance my application by implementing Angular's template Strict mode through the configuration of

"strictTemplates": true

within tsconfig.json. However, encountering an unexpected error after running ng serve with this updated configuration.

One issue I have is with a shared component that is extensively used throughout the application.

@Component({
  selector: 'my-shared-component',
  ...
})
export class SharedComponent {
  @Input() selectedId: string | number;
  @Output() selectedIdChange = new EventEmitter<string | number>()
  @Input() disabled: boolean;
  ...
}

Specifying

<my-shared-component disabled="true">

triggers an error, which is understandable.

The real challenge arises when attempting to pass a number into the

@Input() selectedId: string | number;

, such as:

export class OtherComponent {
  myNumberId: number;
  ...
}

<my-shared-component [(selectedId)]="myNumberId">

An error is then thrown:

TS2322: Type 'string | number' is not assignable to type 'number'

Refactoring the data type of myNumberId to string | number is not a feasible solution since it is also utilized in another component where @Input id: number is required (and must remain a number). Moreover, myNumberId originates from the server and its type is known to be a number, making the replacement with string | number seem inadequate.

Disabling the strictAttributeTypes configuration is not desirable either, as it would eliminate errors triggered by

<my-shared-component disabled="true">

.

I am exploring the possibility of using a typescript utility type (or similar tool) to restrict

@Input() selectedId: string | number

to only accept strings or numbers, without mandating the variables from the parent components to be string | number. Alternatively, I am open to other suggestions for resolving this issue.

angular typescript tsconfig

Answer 1

Answer №1

It's completely understandable that an error is thrown - the EventEmitter output will emit either a string or a number, which conflicts with assigning a value to your strictly typed number.

To resolve this issue, one approach you can take is separating the setter and getter in your OtherComponent:

_myNumberId: number;

get myNumberId(): number {
    return this._myNumberId;
}

get myNumberId(value: string | number): number {
    if (typeof value === 'string') {
        // You may want to use parseFloat() or another method instead of parseInt()
        this._myNumberId = parseInt(value, 10);
    } else {
        this._myNumberId = value;
    }
}

This method allows for preserving the number type for check types when fetching values, while still enabling assignment from both string and number, eliminating the compilation error. However, this solution is not ideal as it appears to be a code smell and compromises type checking on the setter.

An alternative perspective would be to reconsider the concept of an "Id" within your application and utilize a generic component using a defined type, such as:

export type MyId = string | number;

Subsequently, your component could leverage generics by extending this type, ensuring strict type validation:

@Component({
  selector: 'my-shared-component',
  ...
})
export class SharedComponent<T extends MyId> {
  @Input() selectedId: T;
  @Output() selectedIdChange = new EventEmitter<T>()
  @Input() disabled: boolean;
  ...
}

This setup enables the assignment of string or number values in two-way binding, enforcing a single type throughout. If further logic adjustments are necessary for the Id, modifications can be made within the type definition, allowing for easy identification of any type violations.

Alternatively, you have the option to forego defining the type explicitly and structure it like this:

export class SharedComponent<T extends string | number> {

However, considering potential enforcement requirements across different contexts, establishing a custom value type appears to be a more robust solution.

For a demonstration of the generic approach correctly handling both string and number assignments in two-way binding, with an intentional failure when trying to assign a different type (Date), feel free to explore this stackblitz example.

Answer 2

It's completely understandable that an error is thrown - the EventEmitter output will emit either a string or a number, which conflicts with assigning a value to your strictly typed number.

To resolve this issue, one approach you can take is separating the setter and getter in your OtherComponent:

_myNumberId: number;

get myNumberId(): number {
    return this._myNumberId;
}

get myNumberId(value: string | number): number {
    if (typeof value === 'string') {
        // You may want to use parseFloat() or another method instead of parseInt()
        this._myNumberId = parseInt(value, 10);
    } else {
        this._myNumberId = value;
    }
}

This method allows for preserving the number type for check types when fetching values, while still enabling assignment from both string and number, eliminating the compilation error. However, this solution is not ideal as it appears to be a code smell and compromises type checking on the setter.

An alternative perspective would be to reconsider the concept of an "Id" within your application and utilize a generic component using a defined type, such as:

export type MyId = string | number;

Subsequently, your component could leverage generics by extending this type, ensuring strict type validation:

@Component({
  selector: 'my-shared-component',
  ...
})
export class SharedComponent<T extends MyId> {
  @Input() selectedId: T;
  @Output() selectedIdChange = new EventEmitter<T>()
  @Input() disabled: boolean;
  ...
}

This setup enables the assignment of string or number values in two-way binding, enforcing a single type throughout. If further logic adjustments are necessary for the Id, modifications can be made within the type definition, allowing for easy identification of any type violations.

Alternatively, you have the option to forego defining the type explicitly and structure it like this:

export class SharedComponent<T extends string | number> {

However, considering potential enforcement requirements across different contexts, establishing a custom value type appears to be a more robust solution.

For a demonstration of the generic approach correctly handling both string and number assignments in two-way binding, with an intentional failure when trying to assign a different type (Date), feel free to explore this stackblitz example.

Answer 3

Answer №2

Consider substituting string | number for string & number.

Additionally, experiment with sending it in the following format:

<my-component [(id)]="+numberId">

Answer 4

Consider substituting string | number for string & number.

Additionally, experiment with sending it in the following format:

<my-component [(id)]="+numberId">

When attempting to pass a numeric value to the @Input x property with two-way binding in Angular's strict template mode, an error is triggered

Answer №1

Answer №2

Similar questions

Challenges with image cropping in Angular causing performance problems

What is the best way to include a new attribute in a TypeScript internal object?

Steps to prevent uib-timepicker from automatically adjusting time based on the Browser Timezone

Accessing data from a Class in Angular 2

How to bring in a class that was exported using `export = uuid` in Typescript

Data in Angular is not getting transmitted properly through the routing system

Is it possible to import both type and value on the same line when isolatedModules=true?

Is it possible to effectively iterate through an Angular service request?

Error message: The value of ngIf has been altered after it has been checked

"Encountered an issue with Next-Auth session returning as undefined in getServerSideProps using NextJS version 13.2

The Angular Fire Firestore module does not include the 'FirestoreSettingsToken' in its list of exported members

Here is a unique rewrite of the text: "Converting to TypeScript: Add the Node Modules Path to the global paths array in the 'module' module using

What is the best way to refresh existing data retrieved by React Query without having to fetch everything again?

Guide on expanding the capabilities of IterableIterator in TypeScript

The AngularJS 2 TypeScript application has been permanently relocated

npm encountered an abrupt conclusion of JSON input during parsing near "serify":"latest","cha"

Utilize @ngrx/store to merge various reducers from feature modules

Submitting the object in the correct format for the Firebase database

Strategies for avoiding the transformation of a union of tuples into a tuple of unions

In order to conceal the div tag once the animation concludes, I seek to implement React