Skip to content

chore: display error message to match grid label#4047

Open
JamalAlabdullah wants to merge 3 commits intomainfrom
4030-better-handle-how-error-messages-are-shown-for-components-using-innergrid
Open

chore: display error message to match grid label#4047
JamalAlabdullah wants to merge 3 commits intomainfrom
4030-better-handle-how-error-messages-are-shown-for-components-using-innergrid

Conversation

@JamalAlabdullah
Copy link
Contributor

@JamalAlabdullah JamalAlabdullah commented Mar 6, 2026

Description

We have adjusted ComponentStructureWrapper to follow a design decision which was discussed with design team here

  • The validation info messages always placed under the actual input field (not under the label column).
  • The input column should have a minimum width (7 out of 12 columns) to not become too narrow. const MIN_INPUT_COLUMNS = 7; This can be easy changes in future and I made it 7 because 7 cover most validation error message in one line.
  • When labelGrid + innerGrid ≤ 12 the label and field show side by side; but the error message still follows the field.
    This achieved by:
    -- Calculating whether label and input are side‑by‑side (usesSideBySideLabelAndInput).
    -- Checking whether innerGrid is too narrow at any breakpoint (isInputTooNarrow).
    -- Adjusting innerGrid with getInnerGridWithMinInputColumns when needed, so the field gets at least 7 columns.
    -- We always render the field and its error messages inside a single Flex (componentWithValidations) using contentGridSize for its width, and pass that as the only child to Label.”

const componentWithValidations = (
  <Flex
    id={`form-content-${indexedId}`}
    className={className}
    size={contentGridSize}
    style={style}
    item
  >
    {children}
    {showValidationMessages && <AllComponentValidations baseComponentId={baseComponentId} />}
  </Flex>
);

Related Issue(s)

BEFORE Screenshot 2026-03-06 at 09 57 43
AFTER
Screen.Recording.2026-03-16.at.09.31.28.mov

Verification/QA

  • Manual functionality testing
    • I have tested these changes manually
    • Creator of the original issue (or service owner) has been contacted for manual testing (or will be contacted when released in alpha)
    • No testing done/necessary
  • Automated tests
    • Unit test(s) have been added/updated
    • Cypress E2E test(s) have been added/updated
    • No automatic tests are needed here (no functional changes/additions)
    • I want someone to help me make some tests
  • UU/WCAG (follow these guidelines until we have our own)
    • I have tested with a screen reader/keyboard navigation/automated wcag validator
    • No testing done/necessary (no DOM/visual changes)
    • I want someone to help me perform accessibility testing
  • User documentation @ altinn-studio-docs
    • Has been added/updated
    • No functionality has been changed/added, so no documentation is needed
    • I will do that later/have created an issue
  • Support in Altinn Studio
    • Issue(s) created for support in Studio
    • This change/feature does not require any changes to Altinn Studio
  • Sprint board
    • The original issue (or this PR itself) has been added to the Team Apps project and to the current sprint board
    • I don't have permissions to do that, please help me out
  • Labels
    • I have added a kind/* and backport* label to this PR for proper release notes grouping
    • I don't have permissions to add labels, please help me out

Summary by CodeRabbit

  • Refactor

    • Improved responsive form/layout so labels and inputs appear side-by-side when space allows and inputs keep a minimum usable width.
    • Content now expands to full width when needed to avoid cramped inputs; validation message display behavior is unchanged.
  • Tests

    • End-to-end UI assertion made more tolerant to minor CSS variations to reduce flaky failures.

@JamalAlabdullah JamalAlabdullah added kind/other Pull requests containing chores/repo structure/other changes backport-ignore This PR is a new feature and should not be cherry-picked onto release branches labels Mar 6, 2026
@coderabbitai
Copy link
Contributor

coderabbitai bot commented Mar 6, 2026

📝 Walkthrough

Walkthrough

Adds internal grid-sizing helpers and logic to ComponentStructureWrapper to compute a constrained contentGridSize (respecting a minimum input column width and label/input side-by-side fit) and uses it for component content sizing; a frontend test's flex assertion was made more tolerant.

Changes

Cohort / File(s) Summary
ComponentStructureWrapper & grid helpers
src/layout/ComponentStructureWrapper.tsx
Adds MIN_INPUT_COLUMNS, GRID_BREAKPOINT_KEYS, and getInnerGridWithMinInputColumns(inner); computes contentGridSize from labelGrid and innerGrid (enforces minimum input columns and checks label/input side-by-side fit); replaces direct grid?.innerGrid usage for content sizing; validation rendering remains gated by showValidationMessages.
E2E test adjustment
test/e2e/integration/frontend-test/formatting.ts
Replaces strict CSS assertion should('have.css', 'flex', '0 1 50%') with a tolerant retrieval and regex match invoke('css', 'flex').should('match', /^0 1 /), allowing variations after the 0 1 prefix.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (4 passed)
Check name Status Explanation
Title check ✅ Passed The title 'chore: display error message to match grid label' is partially related to the changeset. While it mentions error message display and grid labels, the actual implementation also adds grid sizing logic in ComponentStructureWrapper, which is broader than just matching error messages to grid labels.
Linked Issues check ✅ Passed The changes implement the solution to always align error messages to follow the grid definition used by the label (matching the second alternative from issue #4030), which is verified by the introduction of contentGridSize logic in ComponentStructureWrapper.
Out of Scope Changes check ✅ Passed All changes are scoped to implementing the error message grid alignment objective from issue #4030. The grid sizing helpers and contentGridSize calculation in ComponentStructureWrapper, plus the test assertion update, directly support this objective.
Description check ✅ Passed The PR description comprehensively covers design rationale, implementation details, verification approach, and documentation requirements with appropriate checkboxes completed.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
  • 📝 Generate docstrings (stacked PR)
  • 📝 Generate docstrings (commit on current branch)
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch 4030-better-handle-how-error-messages-are-shown-for-components-using-innergrid
📝 Coding Plan
  • Generate coding plan for human review comments

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Tip

Migrating from UI to YAML configuration.

Use the @coderabbitai configuration command in a PR comment to get a dump of all your UI settings in YAML format. You can then edit this YAML file and upload it to the root of your repository to configure CodeRabbit programmatically.

@JamalAlabdullah JamalAlabdullah added kind/feature-request New feature or request kind/other Pull requests containing chores/repo structure/other changes and removed kind/other Pull requests containing chores/repo structure/other changes labels Mar 6, 2026
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.

🧹 Nitpick comments (1)
src/layout/ComponentStructureWrapper.tsx (1)

34-53: Consider making validation Flex sizing consistent with content Flex breakpoints.

The validation Flex (lines 46-51) only specifies xs and md breakpoints, while the content Flex (line 39) spreads grid?.innerGrid which may include sm, lg, or xl values. If innerGrid defines narrower widths at these breakpoints, the validation messages could end up wider than the content they relate to, potentially causing visual misalignment.

If the intent is for validation to always span full width regardless of innerGrid, consider being explicit about all breakpoints:

         <Flex
           item
-          size={{ xs: 12, md: 12 }}
+          size={{ xs: 12, sm: 12, md: 12, lg: 12, xl: 12 }}
         >

Otherwise, if validation width should match content width, consider:

         <Flex
           item
-          size={{ xs: 12, md: 12 }}
+          size={{ xs: 12, ...grid?.innerGrid }}
         >
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@src/layout/ComponentStructureWrapper.tsx` around lines 34 - 53,
componentWithValidations renders two Flex blocks where the content Flex uses
size={{ xs: 12, ...grid?.innerGrid }} but the validation Flex hardcodes size={{
xs: 12, md: 12 }}, causing breakpoint mismatch; update the validation Flex
sizing to match the content Flex by either spreading grid?.innerGrid (size={{
xs: 12, ...grid?.innerGrid }}) or by explicitly providing the same breakpoints
you expect, so AllComponentValidations aligns with the Flex containing children
when showValidationMessages is true (refer to componentWithValidations, Flex,
AllComponentValidations, grid?.innerGrid, showValidationMessages, indexedId,
baseComponentId).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@src/layout/ComponentStructureWrapper.tsx`:
- Around line 34-53: componentWithValidations renders two Flex blocks where the
content Flex uses size={{ xs: 12, ...grid?.innerGrid }} but the validation Flex
hardcodes size={{ xs: 12, md: 12 }}, causing breakpoint mismatch; update the
validation Flex sizing to match the content Flex by either spreading
grid?.innerGrid (size={{ xs: 12, ...grid?.innerGrid }}) or by explicitly
providing the same breakpoints you expect, so AllComponentValidations aligns
with the Flex containing children when showValidationMessages is true (refer to
componentWithValidations, Flex, AllComponentValidations, grid?.innerGrid,
showValidationMessages, indexedId, baseComponentId).

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: a6993d1f-db03-494f-9126-c972544c2a20

📥 Commits

Reviewing files that changed from the base of the PR and between 5e931c9 and 59b9e42.

📒 Files selected for processing (1)
  • src/layout/ComponentStructureWrapper.tsx

@JamalAlabdullah JamalAlabdullah added the squad/utforming Issues that belongs to the named squad. label Mar 6, 2026
@JamalAlabdullah JamalAlabdullah moved this to 🔎 In review in Team Altinn Studio Mar 6, 2026
Copy link
Contributor

@lassopicasso lassopicasso left a comment

Choose a reason for hiding this comment

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

One comment about the width👍

I am unsure, but @Magnusrm mentioned that this change can perhaps be a breaking change for existing apps' layouts.
Maybe we should discuss this with the team on slack and see if someone has any more thoughts around this before we merget it.

{showValidationMessages && (
<Flex
item
size={{ xs: 12, md: 12 }}
Copy link
Contributor

@lassopicasso lassopicasso Mar 6, 2026

Choose a reason for hiding this comment

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

Suggested change
size={{ xs: 12, md: 12 }}
size={{ xs: 12, ...grid?.label?.innerGrid }}

I may be wrong, but shouldn't the validation message have the same width as label? Edit: you could test if your solution works with setting inner-grid on label, and if it doesnt change the width of error message, you can test my suggestion.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I have tested in repo ra0479-02 page 5 and it looks no effect happens and everything looks good , i tested in other pages also.
In the layout json files we have some json that has labelGrid and other do not have , so in line 34
const componentWithValidations = !grid?.labelGrid ? (. added logic to cover both status ,
and if you check the component Label.tsx line 57 it is set to 12 ; size={grid ?? { xs: 12 }} this match line 48 in this component ComponentStructureWrapper.tsx .
so the label Flex item uses size={{ xs: 12 }} and size={{ xs: 12, md: 12 }} uses the same, so i think your suggestion is allready included in the ternary logic.

@JamalAlabdullah JamalAlabdullah moved this from 🔎 In review to 👷 In progress in Team Altinn Studio Mar 15, 2026
@JamalAlabdullah JamalAlabdullah moved this from 👷 In progress to 🔎 In review in Team Altinn Studio Mar 16, 2026
@sonarqubecloud
Copy link

@lassopicasso
Copy link
Contributor

lassopicasso commented Mar 16, 2026

Hei,
kunne du kort forklart hva du kom frem til på denne før jeg tar review på ny? Jeg synes det er litt vanskelig å tyde kode i app-frontend-react uten videre beskrivelse. Du snakket noe med @Annikenkbrathen på squad-kanalen, men usikker på hva konklusjonen ble.

@JamalAlabdullah
Copy link
Contributor Author

Hei, kunne du kort forklart hva du kom frem til på denne før jeg tar review på ny? Jeg synes det er litt vanskelig å tyde kode i app-frontend-react uten videre beskrivelse. Du snakket noe med @Annikenkbrathen på squad-kanalen, men usikker på hva konklusjonen ble.

I added description 👍

@lassopicasso
Copy link
Contributor

lassopicasso commented Mar 17, 2026

I added description 👍

Superb! The PR is well described, and you have proposed a good solution. My main concern is that this will introduce breaking layout changes for many apps.

When I searched for apps using innerGrid, I found that many use values below 7. I used this query: https://altinn.studio/repos/explore/code?q=innerGrid&search_mode=exact

This would also go against the 12-column grid principle our layout system is based on. If an app developer sets innerGrid to 1, it should represent 1/12 of the available width. With this change, setting values like 4 would still result in a width of 7, which could be confusing for developers trying to create narrower inputs.
We have documented for narrow input fields here as well: https://docs.altinn.studio/nb/altinn-studio/v8/guides/design/guidelines/components/input/#lite-input

I should have responded in the Slack thread when you asked about this earlier, but I forgot to read the responses you got.

You could bring this up with the team to see if this is a direction we want to take, supported by the findings @Annikenkbrathen mentioned. If so, we should inform app developers as well and update the documentation. That said, I suspect this kind of breaking change might be received negatively from the app developers, because they must do many changes and we constrain something we earlier offered.

An alternative approach could be to let the error message width follow whichever is wider of the input field or the label. This I think solves SSB's issue, but again go against the findings from Anniken. 🤔

@JamalAlabdullah
Copy link
Contributor Author

I added description 👍

Superb! The PR is well described, and you have proposed a good solution. My main concern is that this will introduce breaking layout changes for many apps.

When I searched for apps using innerGrid, I found that many use values below 7. I used this query: https://altinn.studio/repos/explore/code?q=innerGrid&search_mode=exact

This would also go against the 12-column grid principle our layout system is based on. If an app developer sets innerGrid to 1, it should represent 1/12 of the available width. With this change, setting values like 4 would still result in a width of 7, which could be confusing for developers trying to create narrower inputs. We have documented for narrow input fields here as well: https://docs.altinn.studio/nb/altinn-studio/v8/guides/design/guidelines/components/input/#lite-input

I should have responded in the Slack thread when you asked about this earlier, but I forgot to read the responses you got.

You could bring this up with the team to see if this is a direction we want to take, supported by the findings @Annikenkbrathen mentioned. If so, we should inform app developers as well and update the documentation. That said, I suspect this kind of breaking change might be received negatively from the app developers, because they must do many changes and we constrain something we earlier offered.

An alternative approach could be to let the error message width follow whichever is wider of the input field or the label. This I think solves SSB's issue, but again go against the findings from Anniken. 🤔

What do you thing @olemartinorg ?

@olemartinorg
Copy link
Contributor

This sounds risky to me - I agree it's problematic to introduce a breaking change like this new minimum-width. App developers pushed back on changing the PDF font size because it broke their carefully molded layout, and this will definitely break more than that change ever did.

Luckily we're already working on the next major version, so breaking changes are possible to introduce, you just have to open a PR in the monorepo instead. That's what will become v10 and the next major version when we release it.

As for what is the correct solution, I believe you've looked into it more than I have. I would try to set up a page in one of our test apps with all the possible combinations of grid settings on an input field, and see how (long) validation messages work there (before and after this change).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

backport-ignore This PR is a new feature and should not be cherry-picked onto release branches kind/feature-request New feature or request kind/other Pull requests containing chores/repo structure/other changes squad/utforming Issues that belongs to the named squad.

Projects

Status: 🔎 In review

Development

Successfully merging this pull request may close these issues.

Better handle how error messages are shown for components using innerGrid

3 participants