-
Notifications
You must be signed in to change notification settings - Fork 667
TypeScript Enhancements #1757
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
TypeScript Enhancements #1757
Conversation
|
Hi @suomiy. Thanks for your PR. I'm waiting for a openshift member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
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.
in order to have typed selectors
frontend/public/module/k8s/index.ts
Outdated
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.
to conform to the API:
for example please see "io.k8s.api.core.v1.Pod": { in https://raw.githubusercontent.com/openshift/origin/master/api/swagger-spec/openshift-openapi-spec.json
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.
These are optional types mainly because when fetching a list of k8s resources (using k8sList()), the apiVersion and kind are often omitted from the individual list items.
|
This functionality serves as a base PR for #1731 |
2125f0f to
d196a73
Compare
d196a73 to
e3c8eca
Compare
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.
We already have this defined here:
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.
Thanks, missed that..
frontend/public/module/k8s/index.ts
Outdated
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.
Isn't this always a string?
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.
I am playing with type generation currently (please see #1731). The disscussion is still ongoing if to use a separate repo for the types, pulling them to our code base or not having them.
I found out that some types are generated as string (kubevirt types) but some are generated as Date (openshift types; https://github.com/openshift/origin/blob/master/api/swagger-spec/openshift-openapi-spec.json)
So I figured it might not hurt to have the both options here (used by @console/shared selectors)
But I can remove this for now until the issue with types is resolved, if you prefer.
frontend/package.json
Outdated
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 seems useful, although I'm a little hesitant to rely on a project with so little history and only one contributor.
@christianvogt @vojtechszocs opinion?
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.
cc @alecmerdler
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.
I'd have to play around with it to see if it's more useful than _.get(...) as SomeType, which is what we tend to use now.
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.
Yes, that project is quite new but it is also extremely small - just one wrapper function (https://github.com/RIP21/ts-get/blob/master/src/index.ts). So it would be easy to pull it into our codebase if it goes under.
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.
I dislike using _.get because it's easy to miss when refactoring. Sure casting the result satisfies typescript but it's a crutch.
My first hunch regarding ts-get was that it used try-catch which is going to be slow. Sure enough they have a closed issue of performance:
RIP21/ts-get#3
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.
My first hunch regarding
ts-getwas that it used try-catch which is going to be slow. Sure enough they have a closed issue of performance:
RIP21/ts-get#3
Oh, wow, that is quite a difference
e3c8eca to
f93cc7c
Compare
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.
Could just as easily make the code explicit:
| export const getUid = (value: K8sResourceKind) => get(value, (v) => v.metadata.uid); | |
| export const getUid = (value: K8sResourceKind) => value.metadata ? value.metadata.uid : 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.
We'd want to check for value being undefined as well
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.
Sorry I'm use to working in projects with strict tsconfig options enabled: strictNullChecks = true. I saw value and not value? and assumed it cannot be null|undefined. We should look at tightening the tsconfig settings.
| export const getUid = (value: K8sResourceKind) => get(value, (v) => v.metadata.uid); | |
| export const getUid = (value: K8sResourceKind) => value && value.metadata && value.metadata.uid || undefined; |
f93cc7c to
c3b10ad
Compare
c3b10ad to
17919f4
Compare
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.
removed the ts-get dependency due to the performance issues as discussed.
I do not like the null checking along the way as proposed because it is easy to make a mistake and is tedious to write for longer paths. So I resolved it with type casting.
Thoughts?
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.
Both approaches today are error prone. If we turn on strictNullChecks then being explicit is a better approach because we benefit from full typechecks. _.get will always be error prone.
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.
Shouldn't we rather wait for strictNullChecks to be agreed upon and proceed with this? Such a change would certainly affect the whole code base.
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.
I wasn't implying we enable strictNullChecks.
I'm fine with using _.get. It's used everywhere already and it seems others are ok with continuing to use it over a few null checks.
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.
ok
17919f4 to
e62a2cb
Compare
frontend/public/module/k8s/index.ts
Outdated
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.
I reverted this back to just a string. The type generation will be configurable to map this property to string.
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 a Date
|
/assign @alecmerdler |
e62a2cb to
e5e8283
Compare
alecmerdler
left a comment
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.
/lgtm
|
/ok-to-test |
| const builderImageStreams = imageStreams.filter((imageStream) => isBuilder(imageStream)); | ||
|
|
||
| return builderImageStreams.reduce((builderImages, imageStream) => { | ||
| return builderImageStreams.reduce((builderImages: NormalizedBuilderImages, imageStream) => { |
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.
ERROR in /go/src/github.com/openshift/console/frontend/packages/dev-console/src/utils/imagestream-utils.ts
(90,3): Type 'K8sResourceKind' is not assignable to type 'NormalizedBuilderImages'.
Property 'apiVersion' is incompatible with index signature.
Type 'string' is not assignable to type 'BuilderImage'.
this type error appeared after the changes of apiVersion -> apiVersion?. Not sure why this triggered it but the type has to be specified for the accumulator in reduce function.
|
/test e2e-aws |
alecmerdler
left a comment
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.
/lgtm
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: alecmerdler, suomiy The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
No description provided.