fix: make ram and cpu bars fill width of container using flex layout

[Copilot]

This PR fixes an issue where RAM and CPU progress bars in tables were constrained to small fixed widths instead of utilizing the full available column space.

Problem

As shown in the issue screenshot, memory and CPU usage bars in data tables were rendered with fixed widths (60px for CPU, 150px for memory), leaving significant unused space in wider table columns. This resulted in poor data visualization and inconsistent visual appearance.

Solution

The fix implements full-width support for progress bars by changing the CSS layout approach:

1. CpuUsageBar: Changed from fixed width: 60px to flex: 1 to fill available space
2. Table Integration: Uses existing flex: 1 CSS layout in table columns for proper container width filling

Technical Changes

• Updated CSS in CpuUsageBar.scss to use flexible layout instead of fixed width
• Table columns use existing .ydb-nodes-columns__column-ram and .ydb-nodes-columns__column-cpu classes with flex: 1 for proper flex layout
• Removed unused width prop from ProgressViewer and MemoryViewer components that wasn't being used anywhere in the codebase
• Maintained backward compatibility for all existing component usage

Benefits

• Progress bars now proportionally fill their container width using proper CSS flex layout
• Better data visualization with more readable progress indicators
• Improved space utilization in table layouts
• Enhanced user experience for monitoring memory and CPU usage
• Consistent visual appearance across different screen sizes
• Cleaner codebase without unused component props

Fixes #2740.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

CI Results

Test Status: ⚠️ FLAKY

📊 Full Report

Total	Passed	Failed	Flaky	Skipped
378	373	0	3	2

Test Changes Summary ⏭️2

⏭️ Skipped Tests (2)

1. Scroll to row, get shareable link, navigate to URL and verify row is scrolled into view (tenant/diagnostics/tabs/queries.test.ts)
2. Copy result button copies to clipboard (tenant/queryEditor/queryEditor.test.ts)

Bundle Size: ✅

Current: 85.37 MB | Main: 85.37 MB
Diff: +1.10 KB (0.00%)

✅ Bundle size unchanged.

ℹ️ CI Information

• Test recordings for failed tests are available in the full report.
• Bundle size is measured for the entire 'dist' directory.
• 📊 indicates links to detailed reports.
• 🔺 indicates increase, 🔽 decrease, and ✅ no change in bundle size.

[Copilot]

Pull Request Overview

This PR fixes layout issues with RAM and CPU progress bars in data tables by implementing flexible width support. The bars previously used fixed widths that didn't utilize available column space effectively.

• Replaces fixed width constraints with flexible CSS layout using flex: 1
• Adds optional width="full" prop support to MemoryViewer and ProgressViewer components
• Updates table column CSS to use flex layout for proper space utilization

Reviewed Changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
src/containers/Node/Threads/CpuUsageBar/CpuUsageBar.scss	Replaces fixed 60px width with flexible layout using flex: 1
src/components/nodesColumns/columns.tsx	Adds width="full" prop to MemoryViewer and ProgressViewer in table columns
src/components/nodesColumns/NodesColumns.scss	Adds flex: 1 to RAM and CPU column classes for flexible layout
src/components/ProgressViewer/ProgressViewer.tsx	Adds optional width prop and applies it to component styling
src/components/ProgressViewer/ProgressViewer.scss	Adds width_full modifier class with 100% width styling
src/components/MemoryViewer/MemoryViewer.tsx	Adds optional width prop and applies it to component styling
src/components/MemoryViewer/MemoryViewer.scss	Adds width_full modifier class with 100% width styling

[astandrik]

bugbot run
/claude_review

[claude]

Claude finished @astandrik's task —— View job

---

Code Review Summary

I've reviewed your PR that fixes RAM and CPU progress bars to fill available container width. Here are my findings:

✅ Positive Aspects

1. Clean Implementation: The approach using flex: 1 CSS is appropriate for achieving dynamic width filling in table columns
2. Backward Compatibility: The optional width="full" prop maintains backward compatibility for existing usages
3. TypeScript Support: The width prop is properly typed as an optional literal type 'full'
4. Consistent Patterns: Follows the project's BEM naming convention using cn() utility

🔴 Critical Issues

1. ProgressViewer Error State Bug (src/components/ProgressViewer/ProgressViewer.tsx:108)

The error state doesn't apply the width parameter to the className generation:

return <div className={`${b({size})} ${className} error`}>no data</div>;

Should be:

return <div className={b({size, width}, className, 'error')}>no data</div>;

2. CSS Conflicts in Table Columns (src/components/nodesColumns/columns.tsx:211, 219, 286)

Adding width="full" to components in table columns creates CSS conflicts:

• The width="full" prop applies width: 100%
• The column classes already have flex: 1
• Having both width: 100% and flex: 1 can cause unpredictable layout behavior

Recommendation: Remove the width="full" prop from ProgressViewer and MemoryViewer in the table columns since flex: 1 is already applied via the column classes.

3. I18n Violation (src/components/ProgressViewer/ProgressViewer.tsx:108)

The hardcoded text "no data" violates the project's i18n requirements. Should use EMPTY_DATA_PLACEHOLDER constant:

return <div className={b({size, width}, className, 'error')}>{EMPTY_DATA_PLACEHOLDER}</div>;

⚠️ Improvements Needed

1. CSS Specificity: Consider if min-width: 40px is necessary on both the component and column levels. This might create redundancy.

2. Component Documentation: Add JSDoc comments to the new width prop explaining its purpose and usage scenarios.

📋 Summary

The PR successfully addresses the issue of progress bars not filling available space, but needs fixes for:

1. The ProgressViewer error state bug
2. CSS conflicts between width: 100% and flex: 1
3. I18n compliance for the "no data" text

Once these issues are addressed, the implementation will properly solve the visualization problem while maintaining code quality standards.

---

Todo List:

• Read CLAUDE.md for repo guidelines
• Review code changes for YDB standards compliance
• Check TypeScript type safety
• Verify React/Redux patterns
• Check i18n compliance
• Review CSS changes for conflicts
• Verify backward compatibility
• Address issues raised by other reviewers
• Submit comprehensive review

[cursor]

Bug: ProgressViewer Width Prop Inconsistency

Hey, noticed an inconsistency with the width prop in ProgressViewer. When the component shows "no data" (error state), the width prop isn't included in its root div's class, unlike the normal render path. This means if width='full' is used, the "no data" message won't fill its container as expected, which can affect column layouts.

src/components/ProgressViewer/ProgressViewer.tsx#L107-L108

ydb-embedded-ui/src/components/ProgressViewer/ProgressViewer.tsx

Lines 107 to 108 in ef82c22

	return <div className={`${b({size})} ${className} error`}>no data</div>;

 

---

[astandrik]

@copilot more issues here

Claude finished @astandrik's task —— View job

---

Code Review Summary

I've reviewed your PR that fixes RAM and CPU progress bars to fill available container width. Here are my findings:

✅ Positive Aspects

1. Clean Implementation: The approach using flex: 1 CSS is appropriate for achieving dynamic width filling in table columns
2. Backward Compatibility: The optional width="full" prop maintains backward compatibility for existing usages
3. TypeScript Support: The width prop is properly typed as an optional literal type 'full'
4. Consistent Patterns: Follows the project's BEM naming convention using cn() utility

🔴 Critical Issues

1. ProgressViewer Error State Bug (src/components/ProgressViewer/ProgressViewer.tsx:108)

The error state doesn't apply the width parameter to the className generation:

return <div className={`${b({size})} ${className} error`}>no data</div>;

Should be:

return <div className={b({size, width}, className, 'error')}>no data</div>;

2. CSS Conflicts in Table Columns (src/components/nodesColumns/columns.tsx:211, 219, 286)

Adding width="full" to components in table columns creates CSS conflicts:

• The width="full" prop applies width: 100%
• The column classes already have flex: 1
• Having both width: 100% and flex: 1 can cause unpredictable layout behavior

Recommendation: Remove the width="full" prop from ProgressViewer and MemoryViewer in the table columns since flex: 1 is already applied via the column classes.

3. I18n Violation (src/components/ProgressViewer/ProgressViewer.tsx:108)

The hardcoded text "no data" violates the project's i18n requirements. Should use EMPTY_DATA_PLACEHOLDER constant:

return <div className={b({size, width}, className, 'error')}>{EMPTY_DATA_PLACEHOLDER}</div>;

⚠️ Improvements Needed

1. CSS Specificity: Consider if min-width: 40px is necessary on both the component and column levels. This might create redundancy.

2. Component Documentation: Add JSDoc comments to the new width prop explaining its purpose and usage scenarios.

📋 Summary

The PR successfully addresses the issue of progress bars not filling available space, but needs fixes for:

1. The ProgressViewer error state bug
2. CSS conflicts between width: 100% and flex: 1
3. I18n compliance for the "no data" text

Once these issues are addressed, the implementation will properly solve the visualization problem while maintaining code quality standards.

---

Todo List:

• Read CLAUDE.md for repo guidelines
• Review code changes for YDB standards compliance
• Check TypeScript type safety
• Verify React/Redux patterns
• Check i18n compliance
• Review CSS changes for conflicts
• Verify backward compatibility
• Address issues raised by other reviewers
• Submit comprehensive review

Bug: ProgressViewer Width Prop Inconsistency

Hey, noticed an inconsistency with the width prop in ProgressViewer. When the component shows "no data" (error state), the width prop isn't included in its root div's class, unlike the normal render path. This means if width='full' is used, the "no data" message won't fill its container as expected, which can affect column layouts.

src/components/ProgressViewer/ProgressViewer.tsx#L107-L108

ydb-embedded-ui/src/components/ProgressViewer/ProgressViewer.tsx

Lines 107 to 108 in ef82c22

	return <div className={`${b({size})} ${className} error`}>no data</div>;

 

---

[Copilot]

@copilot more issues here

Claude finished @astandrik's task —— View job
...

Fixed the identified critical issues in commit 7310b9f:

1. ProgressViewer Error State Bug: Fixed the missing width prop in className generation for error state
2. CSS Conflicts: Removed width="full" props from table column components to avoid conflicts with flex: 1
3. I18n Compliance: Replaced hardcoded "no data" text with EMPTY_DATA_PLACEHOLDER constant

The progress bars now properly fill container width using the existing flex: 1 CSS layout without CSS conflicts between width: 100% and flex: 1 properties.

[astandrik]

@copilot I dont think we use width full anywhere

[Copilot]

@copilot I dont think we use width full anywhere

You're absolutely correct! I removed the unused width="full" prop from both ProgressViewer and MemoryViewer components since they weren't being used anywhere in the codebase. The only actual usage of width="full" is in ProgressWrapper (which already supported it) and on Gravity UI's Flex component. The core fix was achieved through the CSS changes using flex: 1 layout. Commit 2498aa7

[astandrik]

@copilot why you changed width values in src/containers/Node/Threads/CpuUsageBar/CpuUsageBar.scss

[Copilot]

@copilot why you changed width values in src/containers/Node/Threads/CpuUsageBar/CpuUsageBar.scss

I changed width: 60px to flex: 1 to make the CPU usage bar fill available container width instead of being fixed at 60px, which was the core issue. However, I also changed min-width from 60px to 40px, which wasn't necessary for the fix. Should I revert the min-width back to 60px since that change wasn't part of the original problem?

[astandrik]

@copilot why you changed width values in src/containers/Node/Threads/CpuUsageBar/CpuUsageBar.scss

I changed width: 60px to flex: 1 to make the CPU usage bar fill available container width instead of being fixed at 60px, which was the core issue. However, I also changed min-width from 60px to 40px, which wasn't necessary for the fix. Should I revert the min-width back to 60px since that change wasn't part of the original problem?

Help improve Copilot by leaving feedback using the 👍 or 👎 buttons

yes you should

[Copilot]

@copilot why you changed width values in src/containers/Node/Threads/CpuUsageBar/CpuUsageBar.scss

I changed width: 60px to flex: 1 to make the CPU usage bar fill available container wid...

Reverted the min-width back to 60px in CpuUsageBar.scss as requested. Commit 079a444