chore(resource-adm): Remove imports of designsystemet react components #14381
Conversation
…porting directly from designsystem
…w it is done in studio)
…signsystemet-react-components
github-actions
bot
added
solution/studio/designer
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #14381 +/- ##
==========================================
- Coverage 95.65% 95.65% -0.01%
==========================================
Files 1877 1875 -2
Lines 24395 24371 -24
Branches 2806 2806
==========================================
- Hits 23335 23312 -23
+ Misses 799 798 -1
Partials 261 261 ☔ View full report in Codecov by Sentry. |
mgunnerud
added
skip-releasenotes
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
…t-react-components' of https://github.com/Altinn/altinn-studio into chore/14375-resourceadm-remove-imports-of-designsystemet-react-components
📝 WalkthroughWalkthroughThe pull request introduces a comprehensive refactoring of the frontend components in the resourceadm section, primarily focusing on replacing UI components from the Changes
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
…signsystemet-react-components
…signsystemet-react-components
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🔭 Outside diff range comments (1)
frontend/resourceadm/components/MergeConflict/MergeConflict.test.tsx (1)
Line range hint
16-16: Update test suite name to match the component being tested.The test suite name should be updated to reflect the component being tested.
-describe('MergeConflictModal', () => { +describe('MergeConflict', () => {
🧹 Nitpick comments (6)
frontend/resourceadm/components/ResourcePageInputs/ResourceSwitchInput.tsx (1)
Line range hint
78-90: Consider enhancing accessibility with a more descriptive aria-label.While the current aria-label uses the label prop, consider making it more descriptive by combining it with the toggle state for better screen reader context.
- aria-label={label} + aria-label={`${label} - ${isChecked ? t('resourceadm.enabled') : t('resourceadm.disabled')}`}frontend/resourceadm/components/ImportAltinn3ResourceModal/ImportAltinn3ResourceModal.tsx (2)
49-53: Consider improving the radio group's default value handling.The current workaround using
'-'as a fallback value whenselectedEnvis null could be improved. Instead of relying on a string literal that doesn't match yourEnvIdtype, consider:
- Initializing
selectedEnvwith the first available environment- Making the radio group controlled from the start
- const [selectedEnv, setSelectedEnv] = useState<EnvId | null>(null); + const [selectedEnv, setSelectedEnv] = useState<EnvId>(availableEnvs[0]); return ( // ... - value={selectedEnv ?? '-'} // bug: default value of radio cannot be null or undefined + value={selectedEnv}
52-52: Improve type safety in the onChange handler.The current implementation casts the string value directly to
EnvIdwithout validation. Consider adding runtime validation to ensure type safety:- onChange={(newEnv: string) => setSelectedEnv(newEnv as EnvId)} + onChange={(newEnv: string) => { + if (availableEnvs.includes(newEnv as EnvId)) { + setSelectedEnv(newEnv as EnvId); + } + }}frontend/resourceadm/pages/MigrationPage/MigrationPage.tsx (1)
60-64: Consider using i18n for spinner title.The spinner title is hardcoded in Norwegian. Consider using the translation function for consistency with other translated content:
- spinnerTitle='Laster inn migreringsstatus' + spinnerTitle={t('resourceadm.loading_migration_status')}frontend/resourceadm/components/ResourceContactPointFields/ResourceContactPointFieldset.tsx (1)
Line range hint
83-125: Consistent implementation of StudioTextfield componentsThe migration of all four text fields to
StudioTextfieldmaintains the same functionality and error handling while following a consistent pattern.However, consider extracting the common props into a shared configuration object to reduce repetition:
const commonTextFieldProps = { onFocus, error: hasError, }; // Usage example: <StudioTextfield {...commonTextFieldProps} label={t('resourceadm.about_resource_contact_label_email')} value={email} onChange={(e) => setEmail(e.target.value)} onBlur={() => onLeaveTextFields({ ...contactPoint, email })} />frontend/resourceadm/components/ResourceSeachBox/ResourceSeachBox.tsx (1)
3-3: Fix typo in filenameThe filename contains a typo: "Seach" should be "Search" (ResourceSeachBox → ResourceSearchBox).
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (52)
frontend/resourceadm/components/AccessListDetails/AccessListDetail.tsx(2 hunks)frontend/resourceadm/components/AccessListEnvLinks/AccessListEnvLinks.tsx(2 hunks)frontend/resourceadm/components/AccessListErrorMessage/AccessListErrorMessage.tsx(2 hunks)frontend/resourceadm/components/AccessListMembers/AccessListMembers.tsx(4 hunks)frontend/resourceadm/components/AccessListMembers/AccessListMembersTable.tsx(2 hunks)frontend/resourceadm/components/ErrorMessage/ErrorMessage.tsx(2 hunks)frontend/resourceadm/components/FieldWrapper/FieldWrapper.tsx(0 hunks)frontend/resourceadm/components/FieldWrapper/index.ts(0 hunks)frontend/resourceadm/components/ImportAltinn3ResourceModal/ImportAltinn3ResourceModal.tsx(2 hunks)frontend/resourceadm/components/ImportResourceModal/ImportResourceModal.tsx(4 hunks)frontend/resourceadm/components/ImportResourceModal/ServiceContent/ServiceContent.tsx(3 hunks)frontend/resourceadm/components/MergeConflict/MergeConflict.module.css(1 hunks)frontend/resourceadm/components/MergeConflict/MergeConflict.test.tsx(3 hunks)frontend/resourceadm/components/MergeConflict/MergeConflict.tsx(1 hunks)frontend/resourceadm/components/MergeConflict/index.ts(1 hunks)frontend/resourceadm/components/MergeConflictModal/MergeConflictModal.module.css(0 hunks)frontend/resourceadm/components/MergeConflictModal/MergeConflictModal.tsx(0 hunks)frontend/resourceadm/components/MergeConflictModal/index.ts(0 hunks)frontend/resourceadm/components/MigrationPanel/MigrationPanel.tsx(3 hunks)frontend/resourceadm/components/NavigationModal/NavigationModal.tsx(2 hunks)frontend/resourceadm/components/NewAccessListModal/NewAccessListModal.tsx(2 hunks)frontend/resourceadm/components/NewResourceModal/NewResourceModal.tsx(2 hunks)frontend/resourceadm/components/ResourceAccessLists/ResourceAccessLists.tsx(3 hunks)frontend/resourceadm/components/ResourceContactPointFields/ResourceContactPointFieldset.tsx(4 hunks)frontend/resourceadm/components/ResourceDeployEnvCard/ResourceDeployEnvCard.tsx(2 hunks)frontend/resourceadm/components/ResourceDeployStatus/ResourceDeployStatus.tsx(2 hunks)frontend/resourceadm/components/ResourceNameAndId/ResourceNameAndId.module.css(1 hunks)frontend/resourceadm/components/ResourceNameAndId/ResourceNameAndId.tsx(4 hunks)frontend/resourceadm/components/ResourcePageInputs/InputFieldErrorMessage.tsx(2 hunks)frontend/resourceadm/components/ResourcePageInputs/ResourceCheckboxGroup.tsx(4 hunks)frontend/resourceadm/components/ResourcePageInputs/ResourceFieldHeader.tsx(2 hunks)frontend/resourceadm/components/ResourcePageInputs/ResourceLanguageTextField.tsx(3 hunks)frontend/resourceadm/components/ResourcePageInputs/ResourceRadioGroup.tsx(3 hunks)frontend/resourceadm/components/ResourcePageInputs/ResourceSwitchInput.tsx(3 hunks)frontend/resourceadm/components/ResourcePageInputs/ResourceTextField.tsx(2 hunks)frontend/resourceadm/components/ResourceReferenceFields/ResourceReferenceFieldset.tsx(6 hunks)frontend/resourceadm/components/ResourceSeachBox/ResourceSeachBox.tsx(2 hunks)frontend/resourceadm/components/ResourceTable/ResourceTable.tsx(2 hunks)frontend/resourceadm/components/RightTranslationBar/RightTranslationBar.test.tsx(2 hunks)frontend/resourceadm/components/RightTranslationBar/RightTranslationBar.tsx(4 hunks)frontend/resourceadm/language/src/nb.json(1 hunks)frontend/resourceadm/pages/AboutResourcePage/AboutResourcePage.test.tsx(7 hunks)frontend/resourceadm/pages/AboutResourcePage/AboutResourcePage.tsx(2 hunks)frontend/resourceadm/pages/AccessListPage/AccessListPage.tsx(2 hunks)frontend/resourceadm/pages/DeployResourcePage/DeployResourcePage.tsx(4 hunks)frontend/resourceadm/pages/ErrorPage/ErrorPage.tsx(2 hunks)frontend/resourceadm/pages/ListAdminPage/ListAdminPage.tsx(3 hunks)frontend/resourceadm/pages/MigrationPage/MigrationPage.tsx(3 hunks)frontend/resourceadm/pages/PageLayout/PageLayout.tsx(4 hunks)frontend/resourceadm/pages/PolicyEditorPage/PolicyEditorPage.tsx(3 hunks)frontend/resourceadm/pages/ResourceDashboardPage/ResourceDashboardPage.tsx(3 hunks)frontend/resourceadm/pages/ResourcePage/ResourcePage.tsx(2 hunks)
💤 Files with no reviewable changes (5)
- frontend/resourceadm/components/FieldWrapper/index.ts
- frontend/resourceadm/components/MergeConflictModal/index.ts
- frontend/resourceadm/components/MergeConflictModal/MergeConflictModal.module.css
- frontend/resourceadm/components/MergeConflictModal/MergeConflictModal.tsx
- frontend/resourceadm/components/FieldWrapper/FieldWrapper.tsx
✅ Files skipped from review due to trivial changes (5)
- frontend/resourceadm/components/MergeConflict/MergeConflict.module.css
- frontend/resourceadm/components/MergeConflict/index.ts
- frontend/resourceadm/components/NewAccessListModal/NewAccessListModal.tsx
- frontend/resourceadm/components/ResourcePageInputs/InputFieldErrorMessage.tsx
- frontend/resourceadm/components/NewResourceModal/NewResourceModal.tsx
⏰ Context from checks skipped due to timeout of 90000ms (3)
- GitHub Check: Build environment and run e2e test
- GitHub Check: Build environment and run e2e test
- GitHub Check: Testing
🔇 Additional comments (99)
frontend/resourceadm/components/ResourcePageInputs/ResourceSwitchInput.tsx (2)
3-3: LGTM! Import changes align with PR objectives.The import statement correctly imports the Studio components, replacing the previous designsystemet components as intended.
Line range hint
69-99: LGTM! Component replacements maintain functionality and props.The Studio components are correctly implemented with all necessary props and maintain the original functionality, including:
- Proper accessibility attributes
- Event handling
- Conditional rendering
- Translation support
frontend/resourceadm/pages/AboutResourcePage/AboutResourcePage.test.tsx (2)
2-2: LGTM: Import of waitFor utilityThe addition of
waitForfrom@testing-library/reactis appropriate for handling asynchronous blur events in the tests.
92-93: LGTM: Consistent handling of blur eventsThe addition of
waitForto handle blur events is a good improvement that:
- Ensures proper handling of asynchronous state updates
- Improves test reliability by waiting for state to settle
- Is consistently applied across all relevant test cases
Also applies to: 119-119, 160-160, 182-182, 218-218, 238-238
frontend/resourceadm/components/ImportAltinn3ResourceModal/ImportAltinn3ResourceModal.tsx (1)
3-3: LGTM! Import changes align with PR objectives.The import statement correctly imports the required Studio components, replacing the previous designsystemet-react components.
frontend/resourceadm/components/AccessListErrorMessage/AccessListErrorMessage.tsx (1)
3-3: LGTM! Component migration looks good.The Alert component has been correctly replaced with StudioAlert while maintaining the same props and functionality.
Also applies to: 25-25
frontend/resourceadm/pages/AccessListPage/AccessListPage.tsx (1)
3-3: LGTM! Component migration looks good.Components have been correctly migrated while maintaining the same props and error handling logic:
- Alert → StudioAlert
- Spinner component migration included
Also applies to: 25-27
frontend/resourceadm/components/AccessListEnvLinks/AccessListEnvLinks.tsx (1)
7-7: LGTM! Component migrations look good.Multiple components have been correctly migrated while maintaining their hierarchy and props:
- Alert → StudioAlert (with severity)
- List → StudioList (maintaining Root/Unordered/Item structure)
- Paragraph → StudioParagraph (with size and spacing)
Also applies to: 37-50
frontend/resourceadm/components/AccessListMembers/AccessListMembersTable.tsx (1)
5-5: LGTM! Component migration looks good.ErrorMessage component has been correctly replaced with StudioErrorMessage while maintaining the same props and error handling logic.
Also applies to: 37-41
frontend/resourceadm/components/RightTranslationBar/RightTranslationBar.tsx (5)
4-10: LGTM! Import changes align with PR objectives.The component imports have been successfully migrated from
@digdir/designsystemet-reactto@studio/components.
Line range hint
77-89: LGTM! StudioTextarea implementation is correct.The component migration maintains all necessary props and functionality while following the new design system guidelines.
Line range hint
90-99: LGTM! StudioTextfield implementation is correct.The component migration maintains all necessary props and functionality while following the new design system guidelines.
110-112: LGTM! StudioHeading implementation is correct.The heading maintains proper accessibility with level 2 and appropriate sizing.
114-118: LGTM! StudioAlert with StudioParagraph implementation is correct.The alert component maintains proper structure with appropriate severity and consistent text sizing.
frontend/resourceadm/components/RightTranslationBar/RightTranslationBar.test.tsx (3)
31-31: LGTM! Test expectation correctly updated.The test now properly verifies that the complete text is passed to
onLanguageChangeinstead of just the last character, which better reflects the expected component behavior.
47-47: LGTM! Consistent test behavior.The test expectation is correctly updated to match the textarea test case, ensuring consistent behavior verification across both input types.
Line range hint
1-72: Verify component import changes.The tests look good, but let's verify that the corresponding
RightTranslationBarcomponent has been updated to use the new imports from@studio/components.✅ Verification successful
Component imports are properly updated ✅
The
RightTranslationBarcomponent has been successfully migrated to use@studio/componentsand no old imports from@digdir/designsystemet-reactremain. The test file and component implementation are in sync.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify that RightTranslationBar component uses the new imports # Check the component file for old imports echo "Checking for old imports from @digdir/designsystemet-react:" rg "@digdir/designsystemet-react" "frontend/resourceadm/components/RightTranslationBar/RightTranslationBar.tsx" # Check the component file for new imports echo "Checking for new imports from @studio/components:" rg "@studio/components" "frontend/resourceadm/components/RightTranslationBar/RightTranslationBar.tsx"Length of output: 476
frontend/resourceadm/components/MergeConflict/MergeConflict.test.tsx (1)
Line range hint
30-37: LGTM! Test implementation looks good.The test case correctly verifies the reset functionality of the MergeConflict component.
frontend/resourceadm/pages/PageLayout/PageLayout.tsx (2)
21-21: LGTM! State management for merge conflicts is well implemented.The implementation correctly:
- Initializes the merge conflict state
- Updates state based on repo status
- Updates state based on message events
Also applies to: 40-40, 50-50
63-63: LGTM! Conditional rendering is properly implemented.The ternary operator correctly handles the rendering of either the MergeConflict component or the Outlet based on the merge conflict state.
frontend/resourceadm/components/MergeConflict/MergeConflict.tsx (3)
14-23: LGTM! Props are well-typed and documented.The props interface is properly typed and includes clear JSDoc comments for each prop.
34-48: LGTM! Reset functionality is properly implemented.The implementation correctly:
- Uses the reset repository mutation
- Handles the pending state
- Reloads the page on success
50-76: LGTM! Component structure follows best practices.The component:
- Uses proper components from @studio/components as per PR objective
- Implements proper i18n support
- Provides clear user feedback and actions
frontend/resourceadm/language/src/nb.json (1)
261-262: LGTM! Translations are clear and consistent.The added translations for merge conflict messages are clear, consistent with the existing style, and provide proper user guidance.
frontend/resourceadm/components/ResourcePageInputs/ResourceRadioGroup.tsx (3)
3-3: LGTM! Import changes align with PR objectives.The replacement of the Radio component from
@digdir/designsystemet-reactwithStudioRadiofrom@studio/componentsis consistent with the PR's goal.
Line range hint
81-108: LGTM! Component implementation changes are correct.The replacement of Radio components with their Studio equivalents is done correctly:
- Props and functionality remain unchanged
- Error handling is preserved
- Event handling and state management are maintained
Line range hint
1-111: Verify complete removal of designsystemet-react.Let's ensure no references to the old library remain in this file.
✅ Verification successful
Migration to @studio/components is complete
All imports are correctly sourced from @studio/components and other valid internal modules. No references to the old designsystemet-react library remain in this file.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for any remaining references to designsystemet-react in this file rg "@digdir/designsystemet-react" "frontend/resourceadm/components/ResourcePageInputs/ResourceRadioGroup.tsx"Length of output: 107
Script:
#!/bin/bash # Search with broader patterns to catch any variations of the old library rg -i "designsystem" "frontend/resourceadm/components/ResourcePageInputs/ResourceRadioGroup.tsx" # List all import statements in the file for verification rg "^import .* from .*" "frontend/resourceadm/components/ResourcePageInputs/ResourceRadioGroup.tsx"Length of output: 539
frontend/resourceadm/components/ResourceNameAndId/ResourceNameAndId.module.css (1)
37-37: LGTM! Verify responsive layout.The alignment change from
flex-starttoflex-endaligns with the component library migration. However, please verify that the button placement remains visually consistent across different screen sizes.✅ Verification successful
Alignment change verified and approved
The
flex-endalignment is an isolated style specific to the ResourceNameAndId component and aligns with the component library migration. No conflicting patterns were found in related components.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for similar alignment patterns in other components # to ensure consistency across the codebase # Search for similar button wrapper classes with flex alignment rg -g '*.css' -g '*.scss' 'align-self:\s*(flex-start|flex-end)' frontend/resourceadm/Length of output: 190
Script:
#!/bin/bash # Search for the component structure and similar patterns # Find the component file echo "=== Component File ===" fd ResourceNameAndId.tsx$ frontend/resourceadm/ # Check for button wrapper patterns echo -e "\n=== Button Wrapper Patterns ===" rg -g '*.css' -g '*.scss' 'buttonWrapper' frontend/resourceadm/ # Look for flex container patterns echo -e "\n=== Flex Container Patterns ===" rg -g '*.css' -g '*.scss' 'display:\s*flex' frontend/resourceadm/Length of output: 3641
frontend/resourceadm/components/ResourceDeployStatus/ResourceDeployStatus.tsx (2)
8-8: LGTM! Import changes align with PR objectives.The migration from
@digdir/designsystemet-reactto@studio/componentshas been implemented correctly.
55-71: LGTM! Component migration implemented correctly.The replacement of designsystemet components with Studio components has been done consistently while maintaining the same functionality and props.
Let's verify that all designsystemet components have been replaced in this directory:
✅ Verification successful
Migration to Studio components verified successfully
All designsystemet components have been properly replaced with their Studio counterparts, and no legacy imports or usages remain in the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for any remaining designsystemet imports in the ResourceDeployStatus directory rg -l "@digdir/designsystemet-react" "frontend/resourceadm/components/ResourceDeployStatus/"Length of output: 90
Script:
#!/bin/bash # First, verify the directory exists and show its structure fd . "frontend/resourceadm/components/ResourceDeployStatus" # Then, check all imports in the file rg "^import.*from" "frontend/resourceadm/components/ResourceDeployStatus/ResourceDeployStatus.tsx" # Finally, check for any designsystemet component usage (without import) rg -i "Alert|Paragraph|Label" "frontend/resourceadm/components/ResourceDeployStatus/ResourceDeployStatus.tsx"Length of output: 1498
frontend/resourceadm/components/NavigationModal/NavigationModal.tsx (3)
3-3: LGTM! Import changes align with PR objectives.The updated imports correctly source the Studio components from @studio/components package.
44-46: LGTM! Component replacement looks good.The StudioParagraph component is correctly implemented with the appropriate size prop, maintaining the translation functionality.
Line range hint
3-46: Verify consistent component usage across files.Let's ensure the migration from designsystemet to studio components is consistent across all files.
✅ Verification successful
Paragraph component migration is consistent across all files
All instances of Paragraph components in the resourceadm directory are using the new
StudioParagraphfrom@studio/components. The remaining@digdir/designsystemet-reactimports are for unrelated components (ToggleGroup, ErrorSummary, HelpText) and don't affect this specific migration.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check for any remaining @digdir/designsystemet-react imports in resource admin rg -l "@digdir/designsystemet-react" "frontend/resourceadm/" # Check for mixed usage of Paragraph and StudioParagraph rg -l "Paragraph" "frontend/resourceadm/"Length of output: 1552
Script:
#!/bin/bash # Check specific Paragraph imports and usage rg -C 2 "import.*Paragraph" frontend/resourceadm/ # Check actual component usage in files still using designsystemet rg -C 2 "@digdir/designsystemet-react" frontend/resourceadm/Length of output: 6881
frontend/resourceadm/components/MigrationPanel/MigrationPanel.tsx (4)
4-10: LGTM! Import changes align with PR objectives.The migration from
@digdir/designsystemet-reactto@studio/componentsis correctly implemented in the import statements.
100-111: LGTM! Modal dialog components correctly migrated.The Alert and Checkbox components have been properly replaced with their Studio equivalents while maintaining the same functionality and props.
115-115: LGTM! Main panel components correctly migrated.The Heading and Alert components in the main panel have been properly replaced with their Studio equivalents while preserving all necessary props and functionality.
Also applies to: 126-128, 131-133
4-10: Verify complete migration from @digdir/designsystemet-react.Let's ensure no old imports remain in this file.
✅ Verification successful
Migration from @digdir/designsystemet-react is complete
All UI components in this file are properly migrated to use @studio/components with consistent naming patterns and proper implementation.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for any remaining @digdir/designsystemet-react imports in the file # Search for any remaining @digdir/designsystemet-react imports rg "@digdir/designsystemet-react" "frontend/resourceadm/components/MigrationPanel/MigrationPanel.tsx"Length of output: 99
Script:
#!/bin/bash # Get the complete file content cat "frontend/resourceadm/components/MigrationPanel/MigrationPanel.tsx" # Also search for common Digdir component names without the import path rg -i "button|alert|checkbox|heading|modal" "frontend/resourceadm/components/MigrationPanel/MigrationPanel.tsx"Length of output: 6981
frontend/resourceadm/pages/MigrationPage/MigrationPage.tsx (3)
4-10: LGTM! Import changes align with PR objectives.The migration from
@digdir/designsystemet-reactto@studio/componentshas been properly implemented in the import statements.
Line range hint
70-95: LGTM! UI components properly migrated.The migration of UI components maintains proper:
- Component hierarchy
- Accessibility attributes
- Props and styling
1-1: Verify CSS module compatibility.Since we're importing CSS from
MigrationPage.module.css, let's verify if any CSS adjustments are needed for the new Studio components.✅ Verification successful
No CSS adjustments needed ✅
The CSS module uses generic layout styles and design tokens that are compatible with Studio components.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check if the CSS module contains any specific styling for the old components rg -i "digdir|designsystemet" frontend/resourceadm/pages/MigrationPage/MigrationPage.module.cssLength of output: 97
Script:
#!/bin/bash # First check if the file exists fd "MigrationPage.module.css" frontend/resourceadm/pages/MigrationPage/ # If it exists, show its contents fd "MigrationPage.module.css" frontend/resourceadm/pages/MigrationPage/ -x cat {}Length of output: 707
frontend/resourceadm/components/ResourceReferenceFields/ResourceReferenceFieldset.tsx (2)
3-3: LGTM! Import changes align with PR objectives.The import statement correctly imports the Studio components from
@studio/components, replacing the previous imports from@digdir/designsystemet-react.
Line range hint
145-202: LGTM! Component migrations are consistent and maintain functionality.The Studio components are correctly implemented with all necessary props and event handlers preserved from the original implementation.
Let's verify that all designsystemet-react components have been replaced:
✅ Verification successful
All components successfully migrated to Studio versions
The file exclusively uses Studio components (
StudioFieldset,StudioNativeSelect,StudioTextfield) imported from '@studio/components' with no remaining designsystemet-react dependencies.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Verify no remaining @digdir/designsystemet-react imports in this component rg "@digdir/designsystemet-react" "frontend/resourceadm/components/ResourceReferenceFields/ResourceReferenceFieldset.tsx"Length of output: 119
Script:
#!/bin/bash # Check all import statements in the file ast-grep --pattern 'import { $$$ } from "$_"' "frontend/resourceadm/components/ResourceReferenceFields/ResourceReferenceFieldset.tsx"Length of output: 133
Script:
#!/bin/bash # View the file content to verify imports and component usage cat "frontend/resourceadm/components/ResourceReferenceFields/ResourceReferenceFieldset.tsx"Length of output: 5910
frontend/resourceadm/components/ResourcePageInputs/ResourceLanguageTextField.tsx (4)
3-3: LGTM! Import changes align with PR objectives.The transition to
@studio/componentsmatches the intended goal of removing imports from@digdir/designsystemet-react.
108-118: Well-structured event handler refactoring!The split into type-specific handlers (
onChangeNbTextFieldandonChangeNbTextArea) improves type safety while maintaining functionality. The shared logic extraction intoonNbFieldValueChangedfollows good software engineering principles.
130-141: LGTM! Component migration maintains feature parity.The replacement of components with
StudioTextareaandStudioTextfieldpreserves all functionality, including error handling, accessibility features, and conditional rendering.Also applies to: 144-155
Line range hint
1-168: Verify complete removal of designsystemet imports.Let's ensure no references to the old library remain in this file.
✅ Verification successful
Migration to @studio/components is complete and correct
The file has been successfully migrated to use
@studio/componentswith no remaining references to the old designsystemet library.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for any remaining references to @digdir/designsystemet-react # Search for any remaining imports or references to designsystemet rg "@digdir/designsystemet-react" "frontend/resourceadm/components/ResourcePageInputs/ResourceLanguageTextField.tsx" # Search for any Textarea or Textfield components that might not have been migrated ast-grep --pattern 'Textarea' "frontend/resourceadm/components/ResourcePageInputs/ResourceLanguageTextField.tsx" ast-grep --pattern 'Textfield' "frontend/resourceadm/components/ResourcePageInputs/ResourceLanguageTextField.tsx"Length of output: 337
Script:
#!/bin/bash # First verify the file exists and check its content ls -l frontend/resourceadm/components/ResourcePageInputs/ResourceLanguageTextField.tsx # Search with case-insensitive pattern for any possible designsystemet references rg -i "designsystemet" "frontend/resourceadm/components/ResourcePageInputs/ResourceLanguageTextField.tsx" # Search for any old component patterns that might have been missed rg -i "digdir" "frontend/resourceadm/components/ResourcePageInputs/ResourceLanguageTextField.tsx" # Verify the new studio components are properly imported rg "@studio/components" "frontend/resourceadm/components/ResourcePageInputs/ResourceLanguageTextField.tsx"Length of output: 593
frontend/resourceadm/components/ImportResourceModal/ImportResourceModal.tsx (4)
14-20: LGTM! Import changes align with PR objectives.The migration from
@digdir/designsystemet-reactto@studio/componentsis implemented correctly using named imports.
Line range hint
127-142: Verify the portal={false} behavior for StudioCombobox.While the migration to StudioCombobox looks correct, setting
portal={false}might affect the dropdown positioning within the modal. Please ensure this doesn't cause any UI/UX issues, especially with dropdown visibility or z-index stacking.
Line range hint
157-169: LGTM! Studio components migration is properly implemented.The replacement of Paragraph and Textfield components with their Studio equivalents maintains all necessary functionality, including error handling and value management.
Line range hint
1-177: Verify consistent component usage across the codebase.Let's ensure all related components have been migrated consistently from
@digdir/designsystemet-reactto@studio/components.✅ Verification successful
Component migration verified successfully
The file has correctly migrated all its components to
@studio/components. While there are still a few components from@digdir/designsystemet-reactin other files (HelpText, ErrorSummary, and ToggleGroup), the ImportResourceModal component itself shows consistent usage of the new component library.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for any remaining @digdir/designsystemet-react imports in the frontend/resourceadm directory echo "Checking for remaining @digdir/designsystemet-react imports..." rg -l "@digdir/designsystemet-react" frontend/resourceadm/ echo "Verifying consistent Studio component usage..." rg -l "@studio/components" frontend/resourceadm/Length of output: 3798
Script:
#!/bin/bash # Check what specific components are still being imported from @digdir/designsystemet-react echo "Checking specific @digdir/designsystemet-react component imports..." rg "import.*from '@digdir/designsystemet-react'" -A 1 frontend/resourceadm/pages/ListAdminPage/ListAdminPage.tsx frontend/resourceadm/pages/AboutResourcePage/AboutResourcePage.tsx frontend/resourceadm/components/ResourceContactPointFields/ResourceContactPointFieldset.tsxLength of output: 1259
frontend/resourceadm/components/ResourceDeployEnvCard/ResourceDeployEnvCard.tsx (2)
6-12: LGTM! Import changes align with PR objectives.The migration from
@digdir/designsystemet-reactto@studio/componentsis properly implemented in the import section.
68-68: Verify component prop changes and consider adding documentation.The component migrations look good, with special attention to the prop change from
titletospinnerTitlein the StudioSpinner component. Consider adding documentation comments about the new Studio components for better maintainability.Let's verify the prop changes are consistent across the codebase:
Also applies to: 71-76, 78-80, 87-89, 97-101
✅ Verification successful
Component migration verified, cleanup recommended
The StudioSpinner migration is complete with consistent prop usage across the codebase. However, there are unused imports from '@digdir/designsystemet-react' in the following files that should be cleaned up:
- frontend/resourceadm/components/ResourceContactPointFields/ResourceContactPointFieldset.tsx
- frontend/resourceadm/pages/AboutResourcePage/AboutResourcePage.tsx
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for any remaining old component usages and verify prop consistency # Check for any remaining old component imports rg -l "@digdir/designsystemet-react" "frontend/resourceadm" # Check for consistent prop usage in StudioSpinner rg "StudioSpinner" "frontend/resourceadm" -A 2 # Check for any remaining old Spinner components with 'title' prop rg "Spinner.*title=" "frontend/resourceadm"Length of output: 8241
Script:
#!/bin/bash # Check content of files still using old imports echo "=== ResourceContactPointFieldset.tsx ===" rg "Spinner|Paragraph|Tag|Alert" "frontend/resourceadm/components/ResourceContactPointFields/ResourceContactPointFieldset.tsx" -A 1 echo -e "\n=== ListAdminPage.tsx ===" rg "Spinner|Paragraph|Tag|Alert" "frontend/resourceadm/pages/ListAdminPage/ListAdminPage.tsx" -A 1 echo -e "\n=== AboutResourcePage.tsx ===" rg "Spinner|Paragraph|Tag|Alert" "frontend/resourceadm/pages/AboutResourcePage/AboutResourcePage.tsx" -A 1Length of output: 862
frontend/resourceadm/components/ResourceContactPointFields/ResourceContactPointFieldset.tsx (4)
Line range hint
11-71: Well-documented component interface!The component's props interface and documentation are comprehensive and follow best practices.
Line range hint
73-82: Clean migration to StudioFieldsetThe migration to
StudioFieldsetmaintains the same props structure and functionality while aligning with the new component library.
Line range hint
127-135: Error handling implementation looks goodThe error message rendering logic is clean and properly integrated with the new Studio components.
3-4: Consider migrating HelpText to @studio/componentsThere's still a dependency on
@digdir/designsystemet-reactfor theHelpTextcomponent. To fully align with the PR objectives of removing designsystemet react components, consider migrating this component as well.Let's check if a Studio equivalent exists:
frontend/resourceadm/components/ImportResourceModal/ServiceContent/ServiceContent.tsx (5)
4-11: LGTM! Import changes align with PR objectives.The component imports have been successfully migrated from
@digdir/designsystemet-reactto@studio/componentswith appropriate 'Studio' prefixes.
78-86: LGTM! Error handling migration looks good.The error handling has been properly migrated to use
StudioAlertandStudioErrorMessagewhile maintaining the same error display logic.
93-95: LGTM! Empty state handling looks good.The empty state error message has been properly migrated to use
StudioErrorMessage.
Line range hint
99-122: LGTM! Combobox implementation properly migrated.The
StudioComboboximplementation maintains all the necessary functionality:
- Proper portal handling
- Value management
- Filter function
- Empty state and options rendering
67-70: Verify spinner size prop value.The size prop has been changed from 'xlarge' to 'xl'. While this appears to be adapting to the new component API, let's verify the supported values.
✅ Verification successful
The size prop change from 'xlarge' to 'xl' appears to be correct
The StudioSpinner component inherits its size values from a base Spinner component, and the usage of abbreviated size values ('sm', 'xl') is consistent with the component's type system.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for other StudioSpinner usage to confirm size values rg -A 1 "StudioSpinner.*size=" --type typescriptLength of output: 85
Script:
#!/bin/bash # Search for StudioSpinner component definition and usage echo "=== StudioSpinner Component Definition ===" ast-grep --pattern 'interface $_ { $$$ size$_ $$$ }' echo -e "\n=== StudioSpinner Usage Examples ===" rg "StudioSpinner.*size=" -A 1Length of output: 675
Script:
#!/bin/bash # Search for StudioSpinner definition and exports echo "=== StudioSpinner Component ===" rg "export.*StudioSpinner" -A 5 echo -e "\n=== StudioSpinner Type/Interface ===" rg "type.*StudioSpinner|interface.*StudioSpinner" -A 5 echo -e "\n=== All StudioSpinner size props ===" rg "StudioSpinner.*size" -B 1 -A 1Length of output: 5103
frontend/resourceadm/components/ResourcePageInputs/ResourceCheckboxGroup.tsx (3)
3-3: LGTM! Import changes align with PR objectives.The replacement of
@digdir/designsystemet-reactimports with@studio/componentsis implemented correctly.
82-84: LGTM! Component replacement maintains functionality.The
StudioCheckboximplementation preserves all necessary props and behavior from the original component.
Line range hint
94-105: LGTM! Group component replacement is properly implemented.The
StudioCheckbox.Groupimplementation maintains all necessary props and functionality from the original component.Let's verify that the
StudioCheckboxcomponent from@studio/componentshas the same API as the original component:✅ Verification successful
StudioCheckbox.Group API is fully compatible with the usage
The component is a thin wrapper around the design system's Checkbox.Group and supports all the props being used in ResourceCheckboxGroup.tsx. The only difference is that 'small' size should be 'sm', but this is likely handled internally.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify StudioCheckbox component API compatibility # Search for other usages of StudioCheckbox to confirm prop consistency rg -t typescript -t javascript "StudioCheckbox" --no-filename | grep -v "import.*from.*@studio/components" # Search for any type definitions or documentation fd -e ts -e tsx -e js -e jsx . -x grep -l "StudioCheckbox"Length of output: 3996
Script:
#!/bin/bash # Check StudioCheckboxGroup implementation and tests # View the component implementation cat frontend/libs/studio-components/src/components/StudioCheckbox/StudioCheckboxGroup.tsx # View test cases cat frontend/libs/studio-components/src/components/StudioCheckbox/StudioCheckboxGroup.test.tsx # View stories file cat frontend/libs/studio-components/src/components/StudioCheckbox/StudioCheckboxGroup.stories.tsxLength of output: 4818
frontend/resourceadm/components/ResourceTable/ResourceTable.tsx (2)
4-9: LGTM! Clean import organization.The import changes align well with the PR objective of migrating from
@digdir/designsystemet-reactto@studio/components. The grouped imports follow a consistent naming convention with the 'Studio' prefix.
121-123: Verify StudioTag props compatibility.The migration from
TagtoStudioTaglooks correct, but let's verify that the 'info' color and 'small' size props are supported in the new component.✅ Verification successful
StudioTag props are compatible and correctly used
The component is a direct re-export from the official design system (@digdir/designsystemet-react), and the consistent usage patterns across the codebase confirm that both 'info' color and 'small' size props are supported.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for StudioTag documentation or type definitions ast-grep --pattern 'interface StudioTagProps { $$$ }' # Search for other StudioTag usage patterns in the codebase rg "StudioTag.*color=['\"]info['\"]" -A 2 rg "StudioTag.*size=['\"]small['\"]" -A 2Length of output: 2173
Script:
#!/bin/bash # Search for StudioTag component definition ast-grep --pattern 'export const StudioTag = $$$' # Search for StudioTag import source rg "import.*StudioTag.*from" -A 1Length of output: 3319
Script:
#!/bin/bash # Check the StudioTag component file fd "StudioTag" frontend/libs/studio-components/src/components --exec cat {} # Alternatively, search for the props definition ast-grep --pattern 'type StudioTagProps = { $$$ }'Length of output: 210
Script:
#!/bin/bash # List and read files in the StudioTag directory fd . frontend/libs/studio-components/src/components/StudioTag --exec cat {} # Also search for any type definitions with 'color' or 'size' props ast-grep --pattern 'type $_ = { $$$ color?: $_ $$$ }'Length of output: 4386
frontend/resourceadm/components/ResourcePageInputs/ResourceTextField.tsx (4)
3-3: LGTM! Import changes align with PR objectives.The replacement of
@digdir/designsystemet-reactwith@studio/componentsis correctly implemented.
Line range hint
96-111: LGTM! Component replacement is properly implemented.The
StudioTextfieldcomponent is correctly integrated with all necessary props and event handlers.
Line range hint
7-117: LGTM! Component structure maintains best practices.The overall component implementation maintains type safety, proper documentation, and follows React best practices. The changes are focused solely on the component replacement without introducing structural changes.
99-99: Verify the 'size' prop compatibility.Please confirm that the 'small' size variant in
StudioTextfieldmatches the design specifications and behaves consistently with the previous implementation.frontend/resourceadm/pages/ErrorPage/ErrorPage.tsx (1)
3-3: LGTM! Component replacements look goodThe replacements of
HeadingwithStudioHeadingandLinkwithStudioLinkare implemented correctly, maintaining the same functionality and props structure.Also applies to: 16-19
frontend/resourceadm/components/ResourcePageInputs/ResourceFieldHeader.tsx (1)
3-3: LGTM! Tag component replacement is correctThe replacement of
TagwithStudioTagmaintains the same props structure and functionality.Also applies to: 20-22
frontend/resourceadm/components/ResourceSeachBox/ResourceSeachBox.tsx (1)
4-4: LGTM! Textfield component replacement is correctThe replacement of
TextfieldwithStudioTextfieldmaintains the same props structure and functionality.Also applies to: 33-33
frontend/resourceadm/pages/PolicyEditorPage/PolicyEditorPage.tsx (1)
9-9: Verify StudioSpinner prop changesThe component replacements look good, but there are prop changes in StudioSpinner that need verification:
size='xlarge'→size='xl'title→spinnerTitlePlease verify these prop changes align with the
@studio/componentsAPI.Run the following script to verify the StudioSpinner props in the codebase:
Also applies to: 77-80, 105-107
✅ Verification successful
Prop changes are valid
The changes to StudioSpinner props are correct and align with the
@studio/componentsAPI:
- Both
xlandxlargeare valid size values (they are equivalent)spinnerTitleis the correct prop name as defined in the component's interface🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check StudioSpinner usage across the codebase for consistent prop usage # Check for any other instances of StudioSpinner with different size values echo "Checking StudioSpinner size prop usage:" rg -A 2 "StudioSpinner.*size=['\"]" # Check for any other instances of StudioSpinner with title/spinnerTitle prop echo "Checking StudioSpinner title prop usage:" rg -A 2 "StudioSpinner.*(?:title|spinnerTitle)=['\"]"Length of output: 858
Script:
#!/bin/bash # Find all StudioSpinner usages and type definitions echo "All StudioSpinner usages:" ast-grep --pattern 'StudioSpinner $$$' echo -e "\nStudioSpinner type definitions:" rg -A 5 "interface.*StudioSpinner" || rg -A 5 "type.*StudioSpinner" echo -e "\nStudioSpinner imports:" rg "import.*StudioSpinner.*from"Length of output: 9919
Script:
#!/bin/bash # Find SpinnerProps definition and size values echo "Searching for SpinnerProps definition:" rg -A 10 "(?:interface|type).*SpinnerProps.*{" echo -e "\nSearching for size prop values:" rg -A 5 "size\??: ['\"](?:xl|xlarge)['\"]"Length of output: 397
Script:
#!/bin/bash # Check StudioSpinner implementation and size values echo "StudioSpinner component implementation:" cat frontend/libs/studio-components/src/components/StudioSpinner/StudioSpinner.tsx || true echo -e "\nSearching for size values in usage:" rg -l "StudioSpinner.*size=" | xargs rg "size=['\"].*['\"]" echo -e "\nSearching for Spinner size type definition:" rg "type.*Size.*=.*{" -A 5Length of output: 2873
frontend/resourceadm/components/ResourceNameAndId/ResourceNameAndId.tsx (3)
1-1: LGTM! Import changes align with PR objectives.The import statement correctly imports the required components from
@studio/components.
Line range hint
99-155: LGTM! Component replacements maintain functionality.The changes correctly replace design system components with their Studio equivalents while maintaining the same functionality and props.
162-167: Verify size prop value change.The size prop value changed from 'small' to 'sm'. While this works, ensure this is consistent with the design system's size naming convention across the codebase.
frontend/resourceadm/pages/ListAdminPage/ListAdminPage.tsx (2)
4-5: LGTM! Import statements updated correctly.The changes correctly update the imports to use Studio components while maintaining the ToggleGroup from the original design system.
58-60: LGTM! Heading components replaced consistently.The StudioHeading components maintain the same level and size props as the original Heading components.
Also applies to: 94-98
frontend/resourceadm/components/AccessListDetails/AccessListDetail.tsx (3)
11-17: LGTM! Import statements organized correctly.The imports are properly organized and grouped from @studio/components.
120-122: LGTM! Heading component replaced correctly.The StudioHeading maintains the same level and size props.
123-145: LGTM! Textfield components replaced consistently.The StudioTextfield components maintain all necessary props and functionality, including:
- Size prop
- Label and description
- Read-only state
- onChange and onBlur handlers
frontend/resourceadm/components/ResourceAccessLists/ResourceAccessLists.tsx (3)
5-11: LGTM! Import statements organized correctly.The imports are properly organized and grouped from @studio/components.
112-117: LGTM! Heading components replaced consistently.Both StudioHeading components maintain their respective level and size props.
Also applies to: 118-120
Line range hint
125-137: LGTM! Checkbox component replaced correctly.The StudioCheckbox maintains all necessary props and functionality:
- value and checked states
- onChange handler
- Children as label
frontend/resourceadm/pages/ResourceDashboardPage/ResourceDashboardPage.tsx (2)
96-100: LGTM! Spinner component migration looks good.The StudioSpinner component is correctly configured with the required props, including the new
variantprop and renamedspinnerTitleprop.
108-110: LGTM! Heading components properly migrated.The StudioHeading components maintain consistent sizing and proper heading levels for document outline.
Also applies to: 126-133
frontend/resourceadm/components/AccessListMembers/AccessListMembers.tsx (4)
171-177: LGTM! Label and paragraph components properly configured.The StudioLabelAsParagraph and StudioParagraph components are correctly implemented with appropriate size and spacing props.
195-195: LGTM! Alert component properly migrated.The StudioAlert component maintains the correct severity level.
200-208: LGTM! Textfield implementation is correct.The StudioTextfield component properly handles onChange events and maintains debouncing functionality.
218-231: LGTM! Radio group implementation maintains accessibility.The StudioRadio.Group and StudioRadio components are properly configured with appropriate accessibility attributes.
frontend/resourceadm/pages/DeployResourcePage/DeployResourcePage.tsx (3)
201-205: LGTM! Spinner implementation is consistent.The StudioSpinner maintains consistent props with other spinner implementations.
211-223: LGTM! Error handling structure is well-organized.The error display hierarchy using StudioAlert, StudioParagraph, and StudioErrorMessage is properly structured.
243-249: Security attributes properly configured for external link.The StudioLink component includes appropriate security attributes for external links.
frontend/resourceadm/pages/ResourcePage/ResourcePage.tsx (1)
236-240: LGTM! Spinner implementation is consistent.The StudioSpinner component maintains consistent configuration with other spinner implementations in the codebase.
frontend/resourceadm/pages/AboutResourcePage/AboutResourcePage.tsx (2)
102-104: LGTM! Component migration looks goodThe
Headingcomponent has been correctly replaced withStudioHeadingfrom@studio/components, maintaining the same props and functionality.
3-4: Verify if ErrorSummary should be migratedWhile the PR objective is to migrate components from
@digdir/designsystemet-reactto@studio/components,ErrorSummaryis still imported from@digdir/designsystemet-react. Please verify if this component should also be migrated.✅ Verification successful
Mixed usage of both libraries is the current pattern
The codebase shows a consistent pattern of using components from both libraries, where some components are imported from
@studio/componentswhile others remain imported from@digdir/designsystemet-react. TheErrorSummarycomponent is currently only available in@digdir/designsystemet-react, and its usage is consistent with the rest of the codebase.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check if ErrorSummary exists in @studio/components rg -l "export.*ErrorSummary" | grep "@studio/components" # Check if other files still use ErrorSummary from @digdir/designsystemet-react rg "import.*ErrorSummary.*from.*@digdir/designsystemet-react"Length of output: 248
Script:
#!/bin/bash # Check for mixed usage patterns of both libraries rg "import.*from.*@studio/components.*\n.*import.*from.*@digdir/designsystemet-react" -U # Check if there are other components still using @digdir/designsystemet-react rg "import.*from.*@digdir/designsystemet-react" # Look for any documentation about migration strategy fd "README|MIGRATION" --extension md --exec grep -l "designsystemet|studio"Length of output: 52776
frontend/resourceadm/components/ErrorMessage/ErrorMessage.tsx (2)
4-4: LGTM! Import changes align with PR objectives.The change correctly imports the Studio components, following the PR's goal to transition from
@digdir/designsystemet-reactto@studio/components.
21-27: Verify component props compatibility and visual appearance.The migration to Studio components looks correct, maintaining the same props structure. However, we should verify that:
- The props (
size,level) have the same accepted values in the new components- The visual appearance remains consistent with the design system
✅ Verification successful
Component implementation is correct and follows established patterns
The migration to Studio components maintains proper prop usage and visual hierarchy:
- StudioHeading with size='medium' and level={1} is consistent with heading usage across the codebase
- StudioParagraph with size='small' follows the established pattern for error and status messages
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for other usages of these components to verify prop consistency ast-grep --pattern 'StudioHeading size=$_' && \ ast-grep --pattern 'StudioParagraph size=$_'Length of output: 5599
Script:
#!/bin/bash # Search for imports and component usage patterns echo "=== Imports ===" rg "import.*StudioHeading|import.*StudioParagraph" -t tsx -t ts echo -e "\n=== StudioHeading Usage ===" rg "<StudioHeading.*size=|<StudioHeading.*level=" -t tsx echo -e "\n=== StudioParagraph Usage ===" rg "<StudioParagraph.*size=" -t tsx echo -e "\n=== Type Definitions ===" rg "interface.*StudioHeading|interface.*StudioParagraph|type.*StudioHeading|type.*StudioParagraph" -t tsx -t tsLength of output: 640
Script:
#!/bin/bash # Search for imports and component usage patterns with correct syntax echo "=== Imports ===" rg "import.*StudioHeading|import.*StudioParagraph" "*.tsx" "*.ts" echo -e "\n=== StudioHeading Usage ===" rg "<StudioHeading.*size=|<StudioHeading.*level=" "*.tsx" echo -e "\n=== StudioParagraph Usage ===" rg "<StudioParagraph.*size=" "*.tsx" echo -e "\n=== Type Definitions ===" fd -e tsx -e ts -x rg "interface.*StudioHeading|interface.*StudioParagraph|type.*StudioHeading|type.*StudioParagraph" {}Length of output: 726
Script:
#!/bin/bash echo "=== Component Definitions and Imports ===" rg -A 2 "import.*Studio(Heading|Paragraph)" frontend/ echo -e "\n=== StudioHeading Usage ===" rg -A 2 "<StudioHeading" frontend/ echo -e "\n=== StudioParagraph Usage ===" rg -A 2 "<StudioParagraph" frontend/ echo -e "\n=== Looking in Design System ===" fd -e tsx -e ts Studio frontend/ -x rg -l "export.*Studio(Heading|Paragraph)"Length of output: 68049
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
frontend/resourceadm/components/MergeConflict/MergeConflict.test.tsx (2)
Line range hint
27-38: Consider adding more test cases for comprehensive coverage.While the reset functionality is well-tested, consider adding test cases for:
- Error scenarios (e.g., failed reset)
- Edge cases (e.g., multiple reset attempts)
- Other merge conflict resolution paths
Would you like me to help generate additional test cases to improve coverage?
41-49: Consider making the render helper more flexible.The render helper could be enhanced to:
- Accept custom props for different test scenarios
- Allow overriding default values (org, repo)
- Support different router states if needed
Example enhancement:
-const renderMergeConflict = () => { +const renderMergeConflict = (props?: Partial<{org: string; repo: string}>) => { + const defaultProps = { + org: 'ttd', + repo: repoName, + ...props + }; return render( <MemoryRouter> <ServicesContextProvider {...queriesMock} client={createQueryClientMock()}> - <MergeConflict org='ttd' repo={repoName} /> + <MergeConflict {...defaultProps} /> </ServicesContextProvider> </MemoryRouter>, ); };
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (8)
frontend/resourceadm/components/MergeConflict/MergeConflict.test.tsx(3 hunks)frontend/resourceadm/components/ResourceSeachBox/index.ts(0 hunks)frontend/resourceadm/components/ResourceSearchBox/ResourceSearchBox.test.tsx(1 hunks)frontend/resourceadm/components/ResourceSearchBox/ResourceSearchBox.tsx(2 hunks)frontend/resourceadm/components/ResourceSearchBox/index.ts(1 hunks)frontend/resourceadm/language/src/nb.json(2 hunks)frontend/resourceadm/pages/MigrationPage/MigrationPage.tsx(3 hunks)frontend/resourceadm/pages/ResourceDashboardPage/ResourceDashboardPage.tsx(4 hunks)
💤 Files with no reviewable changes (1)
- frontend/resourceadm/components/ResourceSeachBox/index.ts
✅ Files skipped from review due to trivial changes (2)
- frontend/resourceadm/components/ResourceSearchBox/index.ts
- frontend/resourceadm/components/ResourceSearchBox/ResourceSearchBox.test.tsx
🚧 Files skipped from review as they are similar to previous changes (3)
- frontend/resourceadm/language/src/nb.json
- frontend/resourceadm/pages/ResourceDashboardPage/ResourceDashboardPage.tsx
- frontend/resourceadm/pages/MigrationPage/MigrationPage.tsx
⏰ Context from checks skipped due to timeout of 90000ms (3)
- GitHub Check: Build environment and run e2e test
- GitHub Check: Build environment and run e2e test
- GitHub Check: Testing
🔇 Additional comments (5)
frontend/resourceadm/components/MergeConflict/MergeConflict.test.tsx (2)
1-12: LGTM! Clean import structure with proper test utilities.The imports are well-organized and include all necessary testing utilities and mocks.
Line range hint
15-25: LGTM! Proper test setup with clean mock handling.Good practice on:
- Mocking window.location for reload testing
- Cleaning up mocks after each test
- Restoring original window.location
🧰 Tools
🪛 Biome (1.9.4)
[error] 17-17: Avoid the delete operator which can impact performance.
Unsafe fix: Use an undefined assignment instead.
(lint/performance/noDelete)
frontend/resourceadm/components/ResourceSearchBox/ResourceSearchBox.tsx (3)
3-3: LGTM! Fixed typo in CSS module import path.The import path has been corrected from
ResourceSeachBox.module.csstoResourceSearchBox.module.css.
4-4: LGTM! Aligned with PR objective.Successfully replaced the
Textfieldcomponent from@digdir/designsystemet-reactwithStudioTextfieldfrom@studio/components.
33-33: Verify StudioTextfield props compatibility.The component usage looks correct, but let's verify that the
StudioTextfieldcomponent from@studio/componentssupports the same props interface as the previousTextfieldcomponent.✅ Verification successful
Props usage verified successfully.
The
StudioTextfieldcomponent is used consistently across the codebase with the same props interface. The implementation inResourceSearchBoxfollows the established patterns and uses standard props (onChange, label) that are well-supported.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for StudioTextfield component definition to verify props ast-grep --pattern 'export type StudioTextfieldProps = { $$$ }' # Search for any other usages of StudioTextfield to compare prop patterns rg -A 2 '<StudioTextfield'Length of output: 32476
Description
@studio/componentsinstead of from@digdir/designsystemet-reactin resource adminRelated Issue(s)
Verification
Documentation
Summary by CodeRabbit
Based on the comprehensive summary, here are the high-level release notes:
Design System Update
@digdir/designsystemet-reactto@studio/componentsTextfield,Heading,Alert,Spinner, and others with theirStudiocounterpartsMerge Conflict Handling
MergeConflictcomponent to replace the previous modal approachComponent Refactoring
FieldWrappercomponentLocalization
Testing