Skip to content

Conversation

@eranation
Copy link

@eranation eranation commented Apr 3, 2019

This fix is needed for IDEs to not complain about type mismatch, e.g. in cases such as

{{ item.modifiedDate | timeAgo }}

in case modified date is a number.

It works in practice because Date has a constructor that accepts number (milliseconds time stamp), but some IDEAs will complain about the pipe accepting only strings where the attribute is a number.

note: the ? condition seems redundant, but needed for typescript type guard to work. otherwise (at least in TS 2.7.2) it doesn't know to pick the right Date constructor based on the type of value

the ? condition seems redundant, but needed for typescript type guard to work. otherwise (at least in TS 2.7.2) it doesn't know to pick the right Date constructor based on the type of value 

This fix is needed for IDEs to not complain about type mismatch, e.g. in cases such as 

`{{ item.modifiedDate | timeAgo }}`

in case modified date is a number. 

It works in practice because Date has a constructor that accepts number (milliseconds time stamp), but some IDEAs will complain about the pipe accepting only strings where the attribute is a number.
transform(value:string|number) {
this.removeTimer();
let d = new Date(value);
let d = typeof value === 'string' ? new Date(value) : new Date(value);
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The condition here is required unfortunately (at least in TypeScript 2.7.2) - this ensures the type guards treat the first Date(value) as string and the second as number. Without it, TypeScript compiler complains (it won't auto select the matching constructor unfortunately)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant