Skip to content
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

feat: 14951 create new sidegruppe level as an alternate view #15054

Open
wants to merge 38 commits into
base: main
Choose a base branch
from

Conversation

JamalAlabdullah
Copy link
Contributor

@JamalAlabdullah JamalAlabdullah commented Mar 25, 2025

Description

For this issue we worked on frontend part to show the page-groups, we use for now just testing mock to show data until the backend part is done.

Related Issue(s)

Verification

  • Your code builds clean without any errors or warnings
  • Manual testing done (required)
  • Relevant automated test added (if you find this hard, leave it and we'll help out)

Documentation

  • User documentation is updated with a separate linked PR in altinn-studio-docs. (if applicable)

Summary by CodeRabbit

  • New Features

    • Introduced group-based organization in the design view, displaying pages within grouped accordions based on simulated data and feature configuration.
  • Style

    • Enhanced the layout and styling with new visual elements for group headers, icons, containers, and navigation menus, ensuring a cleaner and more organized user interface.
  • Tests

    • Improved test coverage for the DesignView component by incorporating feature flag logic, enhancing the rendering behavior based on feature states.
  • Chores

    • Added a data-testid attribute to enhance testability of the DesignViewNavigation component.

@JamalAlabdullah JamalAlabdullah linked an issue Mar 25, 2025 that may be closed by this pull request
Copy link
Contributor

coderabbitai bot commented Mar 25, 2025

📝 Walkthrough

Walkthrough

This pull request introduces a new type called GroupModel for grouping pages and updates related API types accordingly. Components in the design view are enhanced to render group-based accordions with new mock group data and feature flag checks. Additional CSS classes have been added to style these groups, and minor changes improve test assertion formatting and testability. The layout mock data is also expanded to include a new groups property.

Changes

File(s) Change Summary
frontend/packages/shared/src/types/api/dto/PageModel.ts
frontend/packages/shared/src/types/api/dto/PagesModel.ts
Added a new GroupModel type in PageModel.ts and updated PagesModel to import GroupModel and include a new groups: GroupModel[] property.
frontend/packages/ux-editor/src/containers/DesignView/DesignView.tsx
frontend/packages/ux-editor/src/containers/DesignView/DesignView.module.css
Enhanced the DesignView component to render group accordions via new variables (mockGroups, hasGroups, etc.) and a helper method, with new CSS classes added to support layout and icon styling.
frontend/packages/ux-editor/src/containers/DesignView/PageAccordion/PageAccordion.tsx
frontend/packages/ux-editor/src/containers/DesignView/PageAccordion/PageAccordion.module.css
Updated the PageAccordion component to accept a new optional property navigationMenuClassName for dynamic styling and added a new CSS class .customNavigationMenu.
frontend/packages/ux-editor/src/containers/DesignViewNavigation/DesignViewNavigation.tsx
frontend/packages/ux-editor/src/containers/DesignViewNavigation/DesignViewNavigation.test.tsx
Added a data-testid attribute to the main container in the DesignViewNavigation component and reformatted test assertions for improved clarity.
frontend/packages/ux-editor/src/testing/layoutMock.ts Expanded the pages model mock by adding a new groups property (initialized as an empty array).

Possibly related PRs

Suggested labels

skip-manual-testing

Suggested reviewers

  • Jondyr
  • mlqn
✨ Finishing Touches
  • 📝 Generate Docstrings

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

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)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai plan to trigger planning for file edits and PR creation.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

@github-actions github-actions bot added area/ui-editor Area: Related to the designer tool for assembling app UI in Altinn Studio. solution/studio/designer Issues related to the Altinn Studio Designer solution. frontend labels Mar 25, 2025
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (3)
frontend/language/src/nb.json (1)

1947-1950: Localization Keys: Typos & Consistency

The new keys support the alternate view for side groups as intended by the PR. However, please review the following details:

  • Key "ux_editor.side_oppsett_add_group_division": The value is "Add gruppeinndeling". Consider if the mix of English ("Add") and Norwegian is intentional. It might be preferable to use a fully localized string such as "Legg til gruppeinndeling".
  • Key "ux_editor.side_oppsett_perfome_another_task": The value includes typographical errors – "Utofom en anne oppgave" should likely be corrected to "Utfør en annen oppgave".
  • Keys "ux_editor.side_oppsett_header" and "ux_editor.side_oppsett_remove_group_division": These values are appropriate and consistent.

Please update the text as needed for clarity and full localization.

frontend/packages/ux-editor/src/containers/DesignView/DesignView.tsx (1)

156-201: Implement error handling for missing layout data.

The displayGroupAccordions function has good structure but could benefit from improved error handling:

  1. The function checks if layout exists before proceeding, but lacks explicit error messaging when a layout is missing
  2. The nested layout could be undefined, but there's no fallback rendering

Additionally, there's some code duplication between this function and the original displayPageAccordions function. Consider refactoring common logic into a shared helper function.

- const displayGroupAccordions = !mockGroups.length
-   ? null
-   : mockGroups.map((group) => (
+ const displayGroupAccordions = !mockGroups.length
+   ? null
+   : mockGroups.map((group) => {
+     // Check if group has valid pages before rendering
+     if (!group.pages || group.pages.length === 0) {
+       return null;
+     }
+     return (
        <div key={group.name}>
          <div className={classes.groupHeaderWrapper}>
            <div className={classes.container}>
              <FolderIcon aria-hidden className={classes.liftIcon} />
              <StudioHeading level={3} size='2xs'>
                {group.name}
              </StudioHeading>
            </div>
            <DragVerticalIcon aria-hidden className={classes.rightIcon} />
          </div>

          {group.pages.map((page) => {
            const layout = formLayoutData?.find((formLayout) => formLayout.page === page.id);
-           if (!layout) return null;
+           if (!layout) {
+             console.warn(`Layout not found for page: ${page.id}`);
+             return null;
+           }

            const isInvalidLayout = duplicatedIdsExistsInLayout(layout.data);

            return (
              <div key={page.id} className={classes.groupAccordionWrapper}>
                <PageAccordion
                  key={page.id}
                  pageName={page.id}
                  isOpen={page.id === selectedFormLayoutName}
                  onClick={() => handleClickAccordion(page.id)}
                  isInvalid={isInvalidLayout}
                  hasDuplicatedIds={layoutsWithDuplicateComponents.duplicateLayouts.includes(
                    page.id,
                  )}
                  navigationMenuClassName={classesPageAccordion.customNavigationMenu}
                >
                  {page.id === selectedFormLayoutName && (
                    <FormLayout
                      layout={layout.data}
                      isInvalid={isInvalidLayout}
                      duplicateComponents={layoutsWithDuplicateComponents.duplicateComponents}
                    />
                  )}
                </PageAccordion>
              </div>
            );
          })}
        </div>
-     ));
+     );
+   });
frontend/packages/ux-editor/src/containers/DesignViewNavigation/DesignViewNavigation.test.tsx (1)

58-60: Consider adding more test variations.

The renderDesignViewNavigation helper function is a good practice, but it could be enhanced to support different test scenarios, such as rendering with different props or in different states.

-const renderDesignViewNavigation = () => {
-  return renderWithProviders()(<DesignViewNavigation />);
-};
+const renderDesignViewNavigation = (props = {}) => {
+  return renderWithProviders()(<DesignViewNavigation {...props} />);
+};

Also, consider adding tests for:

  1. Menu item actions when implemented
  2. Keyboard navigation within the dropdown menu
  3. Behavior when a different feature flag configuration is used
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 4cf9178 and e002100.

📒 Files selected for processing (14)
  • frontend/language/src/nb.json (1 hunks)
  • frontend/libs/studio-components/src/components/StudioSectionHeader/StudioSectionHeader.tsx (2 hunks)
  • frontend/packages/shared/src/types/api/dto/PageModel.ts (1 hunks)
  • frontend/packages/shared/src/types/api/dto/PagesModel.ts (1 hunks)
  • frontend/packages/shared/src/utils/featureToggleUtils.test.ts (2 hunks)
  • frontend/packages/shared/src/utils/featureToggleUtils.ts (1 hunks)
  • frontend/packages/ux-editor/src/containers/DesignView/DesignView.module.css (1 hunks)
  • frontend/packages/ux-editor/src/containers/DesignView/DesignView.tsx (2 hunks)
  • frontend/packages/ux-editor/src/containers/DesignView/PageAccordion/PageAccordion.module.css (1 hunks)
  • frontend/packages/ux-editor/src/containers/DesignView/PageAccordion/PageAccordion.tsx (3 hunks)
  • frontend/packages/ux-editor/src/containers/DesignViewNavigation/DesignViewNavigation.module.css (1 hunks)
  • frontend/packages/ux-editor/src/containers/DesignViewNavigation/DesignViewNavigation.test.tsx (1 hunks)
  • frontend/packages/ux-editor/src/containers/DesignViewNavigation/DesignViewNavigation.tsx (1 hunks)
  • frontend/packages/ux-editor/src/containers/DesignViewNavigation/index.ts (1 hunks)
🧰 Additional context used
🧬 Code Definitions (4)
frontend/packages/shared/src/types/api/dto/PagesModel.ts (1)
frontend/packages/shared/src/types/api/dto/PageModel.ts (2)
  • PageModel (1-3)
  • GroupModel (5-10)
frontend/packages/shared/src/utils/featureToggleUtils.test.ts (1)
frontend/packages/shared/src/utils/featureToggleUtils.ts (1)
  • shouldDisplayFeature (34-46)
frontend/packages/ux-editor/src/containers/DesignView/PageAccordion/PageAccordion.tsx (1)
frontend/packages/ux-editor/src/containers/DesignView/PageAccordion/NavigationMenu/NavigationMenu.tsx (1)
  • NavigationMenu (23-89)
frontend/packages/ux-editor/src/containers/DesignView/DesignView.tsx (2)
frontend/packages/ux-editor/src/containers/DesignView/PageAccordion/PageAccordion.tsx (1)
  • PageAccordion (39-109)
frontend/packages/ux-editor/src/containers/DesignViewNavigation/DesignViewNavigation.tsx (1)
  • DesignViewNavigation (8-57)
⏰ Context from checks skipped due to timeout of 90000ms (1)
  • GitHub Check: Testing
🔇 Additional comments (27)
frontend/packages/ux-editor/src/containers/DesignView/PageAccordion/PageAccordion.module.css (1)

35-37: Looks good - new CSS class for navigation menu styling

The addition of the .customNavigationMenu class with a neutral background color aligns well with the purpose of creating a new side group level view. This follows the existing styling patterns in the file and uses the design system's color variables appropriately.

frontend/packages/ux-editor/src/containers/DesignViewNavigation/index.ts (1)

1-1: LGTM - proper module export

This follows the standard pattern for React/TypeScript module organization, making the DesignViewNavigation component easily importable from other parts of the codebase.

frontend/packages/shared/src/types/api/dto/PageModel.ts (1)

5-10: Good type definition for the new GroupModel

The GroupModel type is well-structured for the side group feature, providing the necessary properties for grouping pages together. The design allows for:

  • Named groups with the required name property
  • Nested pages with the pages array
  • Type categorization with the optional type property
  • Completion tracking with the optional markWhenCompleted flag

This implementation provides a solid foundation for the hierarchical structure needed by the side group feature.

frontend/packages/shared/src/utils/featureToggleUtils.ts (1)

16-16: Feature flag for controlled rollout - good approach

Adding the TaskNavigationPageGroups feature flag is a prudent approach that allows for controlled rollout of the side group feature. This follows the established pattern in the codebase for feature flagging and ensures the feature can be toggled on/off without code changes.

Since this isn't added to defaultActiveFeatures, it will be off by default until explicitly enabled, which is appropriate for a new feature.

frontend/packages/ux-editor/src/containers/DesignViewNavigation/DesignViewNavigation.module.css (1)

1-4: LGTM! Clean CSS implementation using design system variables.

The CSS implementation appropriately uses CSS variables (--fds-semantic-surface-neutral-subtle for background color and --properties-width-fraction for flex property) which is good for maintainability and consistency across the application. The selector is properly scoped to the component using CSS modules.

frontend/packages/shared/src/types/api/dto/PagesModel.ts (2)

1-1: Appropriate import addition for the new model type.

The import statement has been correctly updated to include GroupModel alongside PageModel, which is necessary for the type extension below.


5-5: Well-structured type extension to support group functionality.

The PagesModel type has been properly extended with a groups array property of type GroupModel[], aligning with the PR objective to create a new side group level as an alternate view. This type structure correctly establishes the relationship between pages and groups.

frontend/libs/studio-components/src/components/StudioSectionHeader/StudioSectionHeader.tsx (3)

17-17: Good enhancement to component props interface.

Adding an optional menu prop to the StudioSectionHeaderProps type enhances the component's flexibility while maintaining backward compatibility with existing usages.


22-22: Props destructuring correctly updated.

The destructuring of props has been properly updated to include the new menu property, maintaining consistency with the component interface change.


39-39: Appropriate placement of the menu in component rendering.

The menu is conditionally rendered at an appropriate position in the component layout (after the help text), allowing for seamless integration of navigation options.

frontend/packages/shared/src/utils/featureToggleUtils.test.ts (3)

41-49: Well-structured test cases for localStorage feature toggle.

The tests follow the established pattern in the file and properly verify both positive and negative scenarios for the new taskNavigationPageGroups feature flag when set in localStorage.


102-110: Consistent test coverage for URL-based feature toggle.

These test cases maintain the same pattern as other feature flag tests, ensuring the taskNavigationPageGroups feature flag works correctly when specified in the URL parameters.


40-110:

❓ Verification inconclusive

Verify integration with the FeatureFlag enum.

The tests check for a new enum value FeatureFlag.TaskNavigationPageGroups, but there's no evidence in the provided files showing this enum value has been added to the FeatureFlag enum.


🏁 Script executed:

#!/bin/bash
# Check if the TaskNavigationPageGroups flag is defined in the featureToggleUtils.ts file
rg -A 5 -B 5 "export enum FeatureFlag" --include "featureToggleUtils.ts"

Length of output: 514


Manual Verification Needed: Confirm Integration of TaskNavigationPageGroups in FeatureFlag Enum

The test cases in frontend/packages/shared/src/utils/featureToggleUtils.test.ts reference a new enum value—FeatureFlag.TaskNavigationPageGroups—but our initial automated search did not confirm its presence in the FeatureFlag enum. Please manually verify that this enum value is correctly added to the enum (typically defined in a file like frontend/packages/shared/src/utils/featureToggleUtils.ts or a similar location).

  • Ensure the FeatureFlag enum includes TaskNavigationPageGroups.
  • If missing, add it or update the tests accordingly.
frontend/packages/ux-editor/src/containers/DesignView/PageAccordion/PageAccordion.tsx (2)

23-23: Good addition of optional property for enhanced styling flexibility

The optional navigationMenuClassName property allows for contextual styling of the navigation menu, which is helpful for the new side group level feature.


67-107: Structural improvement with proper component nesting

The update properly wraps the Accordion.Item within an Accordion component, which follows the component's intended usage pattern. The conditional class name handling for the navigation menu is also well implemented.

frontend/packages/ux-editor/src/containers/DesignViewNavigation/DesignViewNavigation.tsx (2)

8-11: Good component structure with state management

The component is well-structured with proper state management for the dropdown menu. The use of translation hooks ensures internationalization support.


37-49: Implementation needed for dropdown menu actions

The dropdown menu items have undefined onClick handlers, as noted in the comment. While this is clearly marked as a placeholder, ensure these are implemented in a follow-up task.

Consider creating specific tickets for implementing each action to ensure they don't get overlooked in the development process.

frontend/packages/ux-editor/src/containers/DesignView/DesignView.module.css (2)

17-22: Well-structured CSS for group header layout

The groupHeaderWrapper class appropriately uses flex layout with proper spacing variables to ensure consistent styling across the application.


24-42: Consistent styling approach for icon and container elements

These new CSS classes follow the project's styling patterns, utilizing design system variables for spacing and sizing. The groupAccordionWrapper properly defines margins for nested group content.

frontend/packages/ux-editor/src/containers/DesignView/DesignView.tsx (3)

11-11: Good imports organization to support new functionality.

The new imports properly support the added features - icons for the UI elements, the DesignViewNavigation component, feature toggle utilities, and styling for the page accordion. This demonstrates good preparation for implementing the new side group level feature.

Also applies to: 18-18, 23-25


203-204: Good feature flag implementation.

The code correctly uses feature flags to conditionally render new UI elements. This is a good practice for progressive feature deployment and testing.


209-217: Clean conditional rendering implementation.

The code logic for displaying either group accordions or page accordions is clean and readable. The conditional display of the DesignViewNavigation component based on the feature flag is also well-implemented.

frontend/packages/ux-editor/src/containers/DesignViewNavigation/DesignViewNavigation.test.tsx (5)

1-7: Appropriate test imports and setup.

The test file uses the right imports for testing-library and includes the component under test. The use of mocks for internationalization is particularly good practice.


8-12: Good test for basic rendering.

The first test case properly verifies that the component renders with the correct header text, which is essential for ensuring that internationalization works correctly.


14-24: Good accessibility testing.

These tests properly verify both the menu button's title and its accessibility attribute (aria-haspopup). This is excellent practice for ensuring the component meets accessibility standards.


26-38: Robust interaction testing.

This test properly verifies that the dropdown menu opens when clicking the menu button. The test correctly sets up user interaction, checks the initial state, performs the action, and then verifies the expected outcome.


40-55: Complete dropdown behavior testing.

This test verifies that the dropdown closes when clicking outside, which is an important UX pattern. The use of waitFor to handle asynchronous UI updates is particularly good practice.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (1)
frontend/packages/ux-editor/src/testing/layoutMock.ts (1)

179-182: LGTM - Initial mock groups array is appropriate.

The addition of the empty groups array to pagesModelMock aligns with the PR objective of creating a new side group level as an alternate view. This change provides the foundation for testing the new group functionality.

Consider adding some mock group data to this file to facilitate comprehensive testing of the new side group functionality:

export const pagesModelMock: PagesModel = {
  pages: [{ id: layout1NameMock }, { id: layout2NameMock }],
-  groups: [],
+  groups: [
+    {
+      id: 'group-1',
+      name: 'Group 1',
+      pages: [layout1NameMock]
+    }
+  ],
};
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between e002100 and 4db7cce.

📒 Files selected for processing (1)
  • frontend/packages/ux-editor/src/testing/layoutMock.ts (1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (1)
  • GitHub Check: Testing

@JamalAlabdullah JamalAlabdullah changed the base branch from main to 14949-create-new-sideoppsett-header-to-use-in-utforming-page March 25, 2025 09:52
…der-to-use-in-utforming-page' into 14951-create-new-sidegruppe-level-as-an-alternate-view
Copy link

codecov bot commented Mar 25, 2025

Codecov Report

Attention: Patch coverage is 96.42857% with 1 line in your changes missing coverage. Please review.

Project coverage is 95.94%. Comparing base (f124a8c) to head (cc0098c).
Report is 1 commits behind head on main.

Files with missing lines Patch % Lines
...ux-editor/src/containers/DesignView/DesignView.tsx 95.65% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main   #15054      +/-   ##
==========================================
+ Coverage   95.93%   95.94%   +0.01%     
==========================================
  Files        1996     1996              
  Lines       25869    25890      +21     
  Branches     2921     2928       +7     
==========================================
+ Hits        24817    24841      +24     
+ Misses        788      787       -1     
+ Partials      264      262       -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@github-actions github-actions bot added the quality/testing Tests that are missing, needs to be created or could be improved. label Mar 26, 2025
@JamalAlabdullah
Copy link
Contributor Author

We will wait for this one until this is merged

Base automatically changed from 14949-create-new-sideoppsett-header-to-use-in-utforming-page to main March 27, 2025 10:55
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (2)
frontend/packages/ux-editor/src/containers/DesignView/DesignView.tsx (2)

154-206: Consider refactoring to reduce code duplication.

The displayGroupAccordions function duplicates logic from displayPageAccordions. Consider extracting common rendering logic to a separate function to improve maintainability.

// Add a helper function to render page content
+const renderPageContent = (pageId, layout, isInvalidLayout, duplicateLayouts, duplicateComponents) => {
+  return pageId === selectedFormLayoutName ? (
+    <FormLayout
+      layout={layout.data}
+      isInvalid={isInvalidLayout}
+      duplicateComponents={duplicateComponents}
+    />
+  ) : null;
+};

// Then use this in both displayPageAccordions and displayGroupAccordions

174-177: Improve error handling for missing layouts.

Using console.warn is good for development, but consider providing better user feedback or fallback behavior when a layout is not found for a page.

-if (!layout) {
-  console.warn(`Layout not found for page: ${page.id}`);
-  return null;
+if (!layout) {
+  console.warn(`Layout not found for page: ${page.id}`);
+  // Consider showing an error state or placeholder to the user
+  return (
+    <div key={page.id} className={classes.groupAccordionWrapper}>
+      <div className={classes.errorState}>
+        {t('ux_editor.layout_not_found', { pageId: page.id })}
+      </div>
+    </div>
+  );
}
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 0d9ff95 and cc0098c.

📒 Files selected for processing (4)
  • frontend/packages/ux-editor/src/containers/DesignView/DesignView.test.tsx (4 hunks)
  • frontend/packages/ux-editor/src/containers/DesignView/DesignView.tsx (2 hunks)
  • frontend/packages/ux-editor/src/containers/FormDesigner.test.tsx (0 hunks)
  • frontend/packages/ux-editor/src/containers/FormDesigner.tsx (1 hunks)
💤 Files with no reviewable changes (1)
  • frontend/packages/ux-editor/src/containers/FormDesigner.test.tsx
🧰 Additional context used
🧬 Code Definitions (2)
frontend/packages/ux-editor/src/containers/DesignView/DesignView.test.tsx (1)
frontend/packages/ux-editor/src/testing/layoutMock.ts (1)
  • layout1Mock (134-174)
frontend/packages/ux-editor/src/containers/DesignView/DesignView.tsx (2)
frontend/packages/ux-editor/src/containers/DesignView/PageAccordion/PageAccordion.tsx (1)
  • PageAccordion (38-103)
frontend/packages/ux-editor/src/containers/DesignViewNavigation/DesignViewNavigation.tsx (1)
  • DesignViewNavigation (8-56)
⏰ Context from checks skipped due to timeout of 90000ms (3)
  • GitHub Check: Build environment and run e2e test
  • GitHub Check: Testing
  • GitHub Check: CodeQL
🔇 Additional comments (12)
frontend/packages/ux-editor/src/containers/FormDesigner.tsx (1)

169-169: Feature flag implementation simplified.

The design view is now rendered unconditionally, removing the previous feature flag check. This simplifies the component and moves the feature flag check to the DesignView component itself, which is a good approach for better encapsulation.

frontend/packages/ux-editor/src/containers/DesignView/DesignView.test.tsx (7)

27-32: Good addition of feature toggle mocks for tests.

The mock implementation for featureToggleUtils is well-structured and allows for controlling the feature flag behavior in tests, essential for testing the new conditional rendering logic.


68-68: Properly handling console warnings in tests.

Good practice to suppress console warnings during tests to keep the test output clean. Make sure to restore the spy after each test to prevent affecting other tests.

Also applies to: 84-84, 126-127, 133-134


136-148: Good test coverage for DesignViewNavigation rendering.

These tests properly verify the conditional rendering of the DesignViewNavigation component based on the feature flag, ensuring that the navigation is only displayed when the feature flag is enabled.


150-156: Proper handling of edge cases in tests.

This test correctly verifies that the Accordion is not rendered when there are no pages, which is an important edge case to cover.


158-164: Testing group accordion rendering when feature flag is enabled.

This test properly verifies that group accordions are rendered when the feature flag is enabled and groups are available.


166-173: Verifying fallback to page accordions when feature flag is disabled.

This test properly checks that even when groups are available, they are not rendered when the feature flag is disabled, and instead the standard page accordions are displayed.


175-182: Comprehensive test coverage for page accordion rendering.

This test ensures that the page accordions are rendered correctly when the feature flag is disabled, checking that each page in the order is displayed.

frontend/packages/ux-editor/src/containers/DesignView/DesignView.tsx (4)

11-11: Good imports organization for new functionality.

The new imports are properly added for the required components and icons needed for the group accordion feature. Including the feature flag utilities for conditional rendering is a good practice.

Also applies to: 18-18, 23-24


133-152: Transition plan needed for mock data.

While the mock data approach works well for development, there should be a clear plan for transitioning to real data from the backend.

Consider adding:

  1. A TODO comment with a ticket reference for replacing the mock data
  2. Make sure the mock structure matches the expected API contract
  3. Add error handling for edge cases (e.g., when no pages are available)
#!/bin/bash
# Check if there are existing TODOs for replacing the mock data
rg -A 1 "TODO.*replace.*mock" --glob="*.ts*" frontend/packages/ux-editor/

208-209: Good use of descriptive variables for conditional logic.

Creating named variables for conditions improves readability and makes the code more maintainable. Both hasGroups and isTaskNavigationPageGroups clearly communicate their purpose.


214-222: Clean conditional rendering implementation.

The conditional rendering logic is well-structured and clear. It appropriately checks both the feature flag and the presence of groups before deciding what to render.

@JamalAlabdullah
Copy link
Contributor Author

Actionable comments posted: 0

🧹 Nitpick comments (2)

frontend/packages/ux-editor/src/containers/DesignView/DesignView.tsx (2)> 154-206: Consider refactoring to reduce code duplication.

The displayGroupAccordions function duplicates logic from displayPageAccordions. Consider extracting common rendering logic to a separate function to improve maintainability.

// Add a helper function to render page content
+const renderPageContent = (pageId, layout, isInvalidLayout, duplicateLayouts, duplicateComponents) => {
+  return pageId === selectedFormLayoutName ? (
+    <FormLayout
+      layout={layout.data}
+      isInvalid={isInvalidLayout}
+      duplicateComponents={duplicateComponents}
+    />
+  ) : null;
+};

// Then use this in both displayPageAccordions and displayGroupAccordions

174-177: Improve error handling for missing layouts.
Using console.warn is good for development, but consider providing better user feedback or fallback behavior when a layout is not found for a page.

-if (!layout) {
-  console.warn(`Layout not found for page: ${page.id}`);
-  return null;
+if (!layout) {
+  console.warn(`Layout not found for page: ${page.id}`);
+  // Consider showing an error state or placeholder to the user
+  return (
+    <div key={page.id} className={classes.groupAccordionWrapper}>
+      <div className={classes.errorState}>
+        {t('ux_editor.layout_not_found', { pageId: page.id })}
+      </div>
+    </div>
+  );
}

📜 Review details

No need for refactoring now because the component will be changed after remove test mock and implement changes from backend

@Jondyr Jondyr assigned Jondyr and unassigned Jondyr Apr 1, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/ui-editor Area: Related to the designer tool for assembling app UI in Altinn Studio. frontend quality/testing Tests that are missing, needs to be created or could be improved. solution/studio/designer Issues related to the Altinn Studio Designer solution. team/studio-domain2
Projects
Status: 🔎 Review
Development

Successfully merging this pull request may close these issues.

Create new sidegruppe level as an alternate view
3 participants