-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Strict TS config - Week 1 #606
Conversation
return isTechnical && isNew; | ||
}); | ||
if (news) { | ||
this.technicalNews = news?.filter(newsItem => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This could be changed to this.techicalNews = (news || []).filter(...
, then the if clause can be removed and the type can be array (technicalNews: News[] = [];
)
|
||
downloadedDocumentId: string; | ||
downloadedDocumentId = ''; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of setting a default value, you could make the variable optional downloadedDocumentId?: string
or set the type as downloadedDocumentId: string | undefined
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks fine to me. In the future, it might be better/easier to just change the types and not any values. A change like year: string
-> year = ''
could possible break something, for example if there was a check like if (year === undefined)
somewhere. But I didn't see anything like that here
Could someone review my first week's strict TS config changes? Not sure what to do in situations where a type is now possibly undefined, and it isn't addressed in the code, (see newline 220 on own-datatable.component.ts, or code in technical-news-dumb.component.ts).