upcoming: [UIE-10690, UIE-10691] – Create new Summary section in the NodeBalancer Details tab#13563
upcoming: [UIE-10690, UIE-10691] – Create new Summary section in the NodeBalancer Details tab#13563harsh-akamai wants to merge 3 commits intolinode:developfrom
Conversation
| * but will eventually also look at account capabilities. | ||
| */ | ||
|
|
||
| export const useIsAclpNbMetricsIntegrationEnabled = () => { |
There was a problem hiding this comment.
I don't think we need to create a new hook here since there won't be any customer tag/account capability for this project. To avoid redundant hooks, we can simply use const { aclpNbMetricsIntegration } = useFlags(); wherever this check is needed for this integration work.
There was a problem hiding this comment.
Removed the util 👍
pmakode-akamai
added
NodeBalancers
harsh-akamai
changed the title
Cloud Manager UI test results🔺 1 failing test on test run #3 ↗︎
Details
TroubleshootingUse this command to re-run the failing tests: pnpm cy:run -s "cypress/e2e/core/objectStorage/object-storage.e2e.spec.ts" |
|||||||||||||||||
pmakode-akamai
left a comment
pmakode-akamai
left a comment
There was a problem hiding this comment.
Left some initial comments for now, and it also looks like the changeset is missing. I'll take another look.
| import { EntityHeader } from 'src/components/EntityHeader/EntityHeader'; | ||
| import { StatusIcon } from 'src/components/StatusIcon/StatusIcon'; | ||
|
|
||
| export const getStatusColorMap = ( |
There was a problem hiding this comment.
Let’s move this utility to somewhere in the parent/shared location and add unit tests so it can also be reused in the NodeBalancer landing table.
The naming also feels a bit off here -- could we rename it to something clearer like getNodeBalancerStatus, or if we want something more generic beyond NodeBalancers, either getBackendStatus or getStatusIndicator?
| if (isLoading) { | ||
| return 'inactive'; | ||
| } |
There was a problem hiding this comment.
We usually prefer object params for functions with >=3 args, but in this case we might be able to simplify further.
I think when configs is loading, up and down are likely undefined, so we may not need to pass isLoading into the utility at all. Could we infer the loading state from the absence of these values instead of using isLoading? That would make the utility a bit cleaner and avoid passing a redundant flag.
undefined during loading before removing isLoading
| down?: number | ||
| ) => { | ||
| if (isLoading) { | ||
| return 'inactive'; |
There was a problem hiding this comment.
Is it confirmed that we want to show "inactive" (grey) when both up and down are undefined or loading?
| title: 'Metrics', | ||
| to: '/nodebalancers/$id/metrics', | ||
| hide: !aclpNbMetricsIntegration, | ||
| chip: <NewFeatureChip />, |
There was a problem hiding this comment.
| chip: <NewFeatureChip />, | |
| chip: getFeatureChip(aclp ?? {}), |
Let's use the getFeatureChip utility from the shared package and the aclp flag (used for metrics) to determine the chip here. This will help keep the chips and their behavior consistent with the centralized view.
| import { NodeBalancerConfigurationsWrapper } from './NodeBalancerConfigurationsWrapper'; | ||
| import { NodeBalancerSettings } from './NodeBalancerSettings'; | ||
| import { NodeBalancerSummary } from './NodeBalancerSummary/NodeBalancerSummary'; | ||
| import { NodeBalancerSummaryv2 } from './NodeBalancerSummaryv2/NodeBalancerSummaryv2'; |
There was a problem hiding this comment.
It might be better to rename it to something clearer with proper casing, like NodeBalancerSummaryV2 OR alternatively move the versioning into the folder structure instead of including it in the component name.
| /> | ||
| <span> | ||
| {isConfigsLoading | ||
| ? 'Loading' |
There was a problem hiding this comment.
Is this something we want to display while the values are loading? I think we might need UX input on this.
3 participants
Description 📝
Scope 🚢
Upon production release, changes in this PR will be visible to:
How to test 🧪
Verification steps
Author Checklists
As an Author, to speed up the review process, I considered 🤔
👀 Doing a self review
❔ Our contribution guidelines
🤏 Splitting feature into small PRs
➕ Adding a changeset
🧪 Providing/improving test coverage
🔐 Removing all sensitive information from the code and PR description
🚩 Using a feature flag to protect the release
👣 Providing comprehensive reproduction steps
📑 Providing or updating our documentation
🕛 Scheduling a pair reviewing session
📱 Providing mobile support
♿ Providing accessibility support
As an Author, before moving this PR from Draft to Open, I confirmed ✅