[#1936] Migrate c-summary-charts.vue to TypeScript

[vvidday]

Part of #1936

Proposed commit message

Currently, despite the addition of TypeScript support, the frontend is
still largely written in JavaScript. This results in a lack of type
safety and many complex objects being passed around as unknown types,
which may in turn lead to errors.

Let's migrate one of the main components, c-summary-charts.vue, to
TypeScript. This will provide better type safety and reduce runtime
errors.

Other information

window.getAuthorDisplayName type definition

This PR changes the type for the authorRepos parameter in window.getAuthorDisplayName, from Repo[] to User[]. This was a mistake I made in the initial type definition (as both Repo and User have the displayName attribute).

[zhoukerrr]

@vvidday Just a minor point I want to point out. The rest LGTM!

[ckcherry23]

I have reviewed the code and overall, the TypeScript migration looks great!
However, I do have a comment about the prop types.

I noticed we are using generics to define the types under props in c-summary-charts as Array<string> for example, but in c-summary, we are making use of PropType so the equivalent here would be Array as PropType<string[]>.

Similarly, most of the attributes under data() are defined as [] as string[] but we could make use of generics here as well as [] as Array<string>.

Do you think we can standardize how we define our types using a lint rule?

[vvidday]

I have reviewed the code and overall, the TypeScript migration looks great! However, I do have a comment about the prop types.

I noticed we are using generics to define the types under props in c-summary-charts as Array<string> for example, but in c-summary, we are making use of PropType so the equivalent here would be Array as PropType<string[]>.

Similarly, most of the attributes under data() are defined as [] as string[] but we could make use of generics here as well as [] as Array<string>.

Do you think we can standardize how we define our types using a lint rule?

Great point about generics vs T[] syntax, according to TS docs they are equivalent, but I agree we should stick to one for consistency. Do you have a preference on which?

There does seem to be a lint rule for this, we can either choose generics or the T[] syyntax.

[zhoukerrr]

@vvidday Personally I think the T[] syntax is cleaner and easier to write. But of course the team will have to come to an agreement. The lint rule and refactoring of the code code be done in a separate PR or be made as a good first issue for new developers to familiarise with our codebase.

[ckcherry23]

Great point about generics vs T[] syntax, according to TS docs they are equivalent, but I agree we should stick to one for consistency. Do you have a preference on which?

I think I would prefer the array-simple rule as it uses the more modern T[] syntax for simpler types while allowing Array<T | U> for more complex types (where (T | U)[] may be a confusing syntax). I will create a new issue for this, so that we can tackle it in another PR.

[zhoukerrr]

LGTM. Not sure how to work with the cypress warning regarding the unexpected console statement. I do think it is useful in some cases. Maybe a separate issue could be raise for this for new developers to work on?

[github-actions]

The following links are for previewing this pull request:

• Dashboard Preview: https://dashboard-1976-pr-reposense-reposense.surge.sh
• Docs Preview: https://docs-1976-pr-reposense-reposense.surge.sh