-
Notifications
You must be signed in to change notification settings - Fork 667
shared: move lookup utils from kubevirt-plugin #1966
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
Conversation
|
/test e2e-aws-console-olm |
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.
It's not clear to me how this is used, but it's not unique across types. Is there a reason to avoid simply using the UID?
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.
example usage:
not sure what will be the most prevalent usage:
should I put the getUID function as a default to createLookup when getKey is not specified ?
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.
+1 on favoring UID over a composite ID that may not be unique.
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 like an unaddressed comment, unless I'm missing something.
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.
added the UID selector by default
74b4b3c to
d849f27
Compare
|
/test e2e-aws |
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.
If there's just one file, why not simply put code here instead of adding another utils.ts file?
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 think the need for more utils will come as time goes on, so I think it is better to start folder for that in the beginning.
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, fair enough.
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.
getLookupID fits the signature of KeyResolver, we could use it here.
Also, do we really need to go overboard with generics here?
Can't we just have K8sEntityMap working with <A extends K8sResourceKind> directly? (i.e. do we need to work with objects that aren't structurally compatible with K8sResourceKind?)
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.
getLookupID fits the signature of KeyResolver, we could use it here.
I tried, but failed - we need the generic type A for entity and make it compatible with createLookup
Also, do we really need to go overboard with generics here?
I think it is quite useful to have the exact type returned of entity the lookup was created for (especial once we get in #1813)
Can't we just have K8sEntityMap working with directly? (i.e. do we need to work with objects that aren't structurally compatible with K8sResourceKind?)
we have many other use cases of inner lists which are not structurally compatible with K8sResourceKind, e.g. https://github.com/openshift/console/blob/master/frontend/packages/kubevirt-plugin/src/components/vm-disks/vm-disks.tsx#L63
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, thanks for clarification.
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.
+1 on favoring UID over a composite ID that may not be unique.
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.
👍
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 like an unaddressed comment, unless I'm missing something.
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, thanks for clarification.
c16b78e to
338a5fd
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.
I had to also change signature of these selectors to be compatible with the lookup generics
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.
Well, that's what I meant by being careful with TS generics, since it might force us to add generic type signatures to all code related to e.g. createLookup stuff.
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.
Well, that's what I meant by being careful with TS generics, since it might force us to add generic type signatures to all code related to e.g. createLookup stuff.
|
LGTM - I hope this also addresses Sam's comment #1966 (comment). |
|
@suomiy When dealing with TS generics, it's always a good idea to think about generic type param fallbacks, for example: type Foo<T> = (obj: T) => string;
// when using Foo, you *always* need to provide type param T
type Bar<T = any> = Foo<T>;
// when using Bar, you *may* provide type param T to narrow down the signature |
|
/approve cancel Needs Sam's look. |
|
/lgtm |
thanks, added the |
|
/test e2e-aws-console |
|
/test e2e-aws-console |
|
/lgtm |
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: rawagner, suomiy, vojtechszocs 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 |
|
/test e2e-aws |
1 similar comment
|
/test e2e-aws |
|
/retest |
|
/retest Please review the full test history for this PR and help us cut down flakes. |
|
@suomiy: The following tests failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. 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. I understand the commands that are listed here. |
used by
kubevirtand newlymetal3(#1967)