-
Notifications
You must be signed in to change notification settings - Fork 15
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
NETOBSERV-230 topology view #97
NETOBSERV-230 topology view #97
Conversation
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
efe647e
to
167e4b7
Compare
53122b0
to
e290077
Compare
linked option panel action #98 |
e290077
to
672c680
Compare
type: string | ||
): ComponentType<{ element: GraphElement }> | undefined => { | ||
switch (type) { | ||
//TODO: try different shapes by Owner Kind for example |
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 to this comment, to sync with Andrew
|
||
//TODO: remove kindToAbbr after integration of console ResourceIcon in topology library | ||
const abbrBlacklist = ['ASS']; | ||
export const kindToAbbr = (kind: 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.
isn't it something we can get from the console plugin SDK? I know the console has something similar, we should try to be consistent with them.
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.
The function itself is in console-dynamic-plugin-sdk/src/utils/k8s/k8s-get-resource.ts
but is not exported.
It's related to bridge/api-discovery-resources
you can retrieve in your localStorage
, containing a list of kinds with abbreviations.
If we don't have an alternative we could query these data however it seems there is not the color field on kinds we are looking for.
moved |
1e187c2
to
dfa66cd
Compare
Rebased with #98 so you can now test display options 👍 |
dfa66cd
to
5552ea9
Compare
|
}; | ||
|
||
export const DEFAULT_NODE_TRUNCATE_LENGTH = 25; | ||
export const DEFAULT_NODE_SIZE = 75; |
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 is nitpicking, but still it would be good to get a common approach on that: which naming case for constants?
I tend to follow the other convention, defaultNodeSize
, making no difference between variables and constants, being exported or not, being global or not. I think it's the most common in jasvascript / typescript landscape (though I wouldn't bet on it), it's in the well adopted basarat's TypeScript book or in the TypeScript language convention itself (which does not pretend to be a convention for typescript projects in general)
On the other hand, we have the google approach which makes a difference between global constants and other constants, like you're doing here. The same approach can be seen elsewhere (I don't think ts.dev has anything official with TypeScript, it's just a service company)
Again, this is nitpicking, but if we get a common approach it would be more consistent and we'd clear the current ambiguity that we have while writing code or doing reviews. I'm more used to doing the first option in typescript, but I'm fine to change
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 seems like the console code tend to follow capital-case approach, while not 100% consistent
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'm ok with any. We can centralize all the exported constants to a single folder so it will be easier to maintain with a single convention ?
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 prefer the domain-driven approach than everything-centralized :) Keep the code closer to where it's used, and try to have some domain boundaries, rather than a single constants file that often grows out of control, can easily turn up being messy and sometimes ends up having unused constants that remain unnoticed.. I've been there :)
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 have opened a follow up task since this is not related to that PR
https://issues.redhat.com/browse/NETOBSERV-268
5552ea9
to
107617d
Compare
//TODO: implement context menu | ||
const defaultMenu = createContextMenuItems('TODO'); |
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.
Do you plan to implement it via this PR, or later? Maybe remove / comment-out this code if it's planned for later?
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.
let's remove it, we'll see about the context menus later
Again, nice work!
As an aside, totally unrelated, maybe we should rename our workloads to "netobserv-..."? It would render better on topology. I'm fine if you prefer to address feedback in follow-ups. The only real issue I could see is the incorrect rate for reporter "both". |
@jpinsonneau I'm setting the lgtm label, I think it's fine to merge if you prefer to address feedback in follow-ups, up to you |
sure let's do this => https://issues.redhat.com/browse/NETOBSERV-270 |
This PR is part of NETOBSERV-180 Topology components spike task
It implements basic view component for topology.
Data are faked from a real query result saved in
web/src/components/netflow-topology/__tests__/netflow-topology.spec.tsx
and randomly updated.You can press refresh button to see the changes.
As mentioned in #93 you need to add
topology=preview
in your url arguments if you are not onlocalhost:9000