fix(studio): Consolidate StatusBadge logic#326
Merged
steramae-nvidia merged 2 commits intoJun 13, 2026
Conversation
Signed-off-by: Sean Teramae <steramae@nvidia.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Enterprise Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughStatusBadge is extended to accept an optional config mapping (StatusConfigEntry) and fallback; badge resolution and rendering now use that config or the legacy mapping. Two consumer components (IntakeTelemetryStatusBadge, CustomizationStatusBadge) are refactored to use the shared StatusBadge. Tests added for the config-driven path. ChangesStatusBadge Config-Driven Consolidation
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
web/packages/common/src/components/StatusBadge/index.tsx (1)
36-48: 📐 Maintainability & Code QualityDocument
statusConfigkey case-sensitivity
statusConfigis intentionally case-sensitive (statusConfig[status]), while the legacybadgeStatuspath lowercases (String(status).toLowerCase());StatusBadge.test.tsxasserts"SUCCESS"doesn’t matchSTATUS_CONFIG(case-sensitive), whereas uppercase statuses normalize only on thebadgeStatuspath. Consider calling out this contract for consumers to prevent surprises.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@web/packages/common/src/components/StatusBadge/index.tsx` around lines 36 - 48, The conditional treats statusConfig as case-sensitive (accessed with statusConfig[status]) while the legacy badgeStatus path lowercases the input via statusKey = String(status).toLowerCase(), causing tests like StatusBadge.test.tsx to expect "SUCCESS" not to match STATUS_CONFIG; update the StatusBadge component's public documentation (docblock above the StatusBadge component and/or component props docs) to explicitly state this contract: statusConfig keys are case-sensitive and must match the exact status string, whereas badgeStatus is matched case-insensitively via lowercasing, or alternatively normalize the incoming status before checking statusConfig if you prefer case-insensitive matching; reference statusConfig, badgeStatus, statusKey, and CONFIG_DEFAULT in the doc so consumers know which behavior applies.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@web/packages/common/src/components/StatusBadge/StatusBadge.test.tsx`:
- Around line 159-163: The test in StatusBadge.test.tsx leaves a TODO for
verifying icon rendering; update the it('renders icon when config entry has
one') test to import CircleCheck from lucide-react, create a statusConfig entry
that includes { icon: CircleCheck } (or an icon-bearing config constant), render
<StatusBadge status="error" statusConfig={...} />, and assert the icon is
present (e.g., query for role="img" or the SVG by test id/alt/title depending on
implementation) while keeping the original assertion that the non-icon config
renders no image; reference the StatusBadge component and the test name to
locate where to add the import, config, render call, and assertions.
---
Nitpick comments:
In `@web/packages/common/src/components/StatusBadge/index.tsx`:
- Around line 36-48: The conditional treats statusConfig as case-sensitive
(accessed with statusConfig[status]) while the legacy badgeStatus path
lowercases the input via statusKey = String(status).toLowerCase(), causing tests
like StatusBadge.test.tsx to expect "SUCCESS" not to match STATUS_CONFIG; update
the StatusBadge component's public documentation (docblock above the StatusBadge
component and/or component props docs) to explicitly state this contract:
statusConfig keys are case-sensitive and must match the exact status string,
whereas badgeStatus is matched case-insensitively via lowercasing, or
alternatively normalize the incoming status before checking statusConfig if you
prefer case-insensitive matching; reference statusConfig, badgeStatus,
statusKey, and CONFIG_DEFAULT in the doc so consumers know which behavior
applies.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: d2c185cd-391f-43b8-84fa-de492bc16ea5
📒 Files selected for processing (5)
web/packages/common/src/components/StatusBadge/StatusBadge.test.tsxweb/packages/common/src/components/StatusBadge/badgeStatus.tsxweb/packages/common/src/components/StatusBadge/index.tsxweb/packages/studio/src/components/IntakeTelemetryStatusBadge/index.tsxweb/packages/studio/src/components/dataViews/CustomModelsDataView/CustomizationStatusBadge/index.tsx
Contributor
|
Signed-off-by: Sean Teramae <steramae@nvidia.com>
marcusds
approved these changes
Jun 13, 2026
steramae-nvidia
deleted the
steramae/astd-233-unify-the-statusbadge-components
branch
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary by CodeRabbit
New Features
Tests
Refactor