Considerations for v4

[haakemon]

Description

After v3 comes v4. This issues lists changes we need to (or want to) complete in the breaking changes window for v4.

Breaking changes

Beta Give feedback

1. Fixing inconsistent prev/next navigation buttons #1446
   kind/bug +1
   
2. feat(TextResources): add support for defaultValue in variables in tex… #1441
   kind/product-feature +1
3. Tech debt: Language variables rewrite #1444
   kind/breaking-change +1
4. Change font from Altinn-DIN to Inter #1148
   fe-v4 +1
   
5. Schema validation does not support "flat" data model #975
   fe-v4 kind/bug status/triage +3
6. Define how groups and repeating groups should handle titles #820
   area/table fe-v4 kind/user-story org/pat ux +5
   
7. Custom receipt should render even after reloading the page #1468
   fe-v4 kind/breaking-change kind/feature-request +3
   
8. Removing support for non-layoutset apps #1485
   fe-v4 kind/breaking-change quality/debt +3
   
9. Split up the Group component into different components #1486
   fe-v4 kind/breaking-change quality/debt +3
   

   
10. Single field validation does not run on fields when loading the form #628
    area/validation fe-v4 kind/bug +3
11. The Paragraph component should throw errors if given invalid elements #1487
    fe-v4 kind/breaking-change kind/bug +3
    
12. Summary: Remove pageRef configuration option #1488
    fe-v4 kind/breaking-change +2
    
13. AttachmentList: Clean up configuration options #1489
    fe-v4 kind/breaking-change +2
    
14. Remove tracks functionality (calculatePageOrder) #1491
    1 of 2
    fe-v4 kind/breaking-change +2
    
15. Remove legacy filter option for repeating groups #1493
    fe-v4 kind/breaking-change +2
    
16. Rename AddressComponent -> Address #1495
    fe-v4 kind/breaking-change +2
    
17. Require a minimum backend version in v4 #1496
    fe-v4 kind/breaking-change +2
    
18. Easing the transition to the Inter font #1500
    area/accessibility area/designsystem area/table ux +4
19. Improved summary and PDF experience #1502
    49 of 58
    Epic area/summary kind/feature-request ux +4
    
20. Validate individual components against JsonSchema and produce warnings in DevTools #1512
    area/layout fe-v4 kind/feature-request +3
    

Data model related changes

Beta Give feedback

1. Experiment: Storing the data model in a Context #1175
   area/data-storage fe-v4 feature-complete quality/debt +4
   
2. Validation trigger on group should re-validate on delete + new row #555
   area/validation fe-v4 org/dsb org/ssb +4
   
3. Support multiple data models in the same process task #1484
   kind/feature-request +1
   
4. Checkbox component should support mapping to an array #273
   feature-complete kind/user-story +2
5. List component: remaining issues #925
   area/table kind/product-feature org/lt +3
6. Repeating groups: "openByDefault" åpner ikke gruppen som deles på flere sider #1111
   fe-v4 kind/bug org/ssb +3
7. Repeating groups: Open by default blir feil ved bruk av hiddenRow #1147
   fe-v4 kind/bug org/ssb +3
   
8. Kalkuleringer lagrer ikke data til datamodellfelter som ikke er i skjema #707
   fe-v4 kind/bug org/ssb +3
   
9. Specifying an invalid dataModelBinding in layout silently fails #743
   fe-v4 kind/bug +2
10. Store the display value of a selected codelist entry in the datamodel #1104
    kind/user-story org/ssb +2
    
11. Remove support for storing the data model without using multipart #1490
    area/data-storage fe-v4 quality/debt +3
    
12. Diffing the data model after saving on the backend #1501
    fe-v4 kind/breaking-change kind/feature-request +3
    

Features, non-breaking and others

Beta Give feedback

1. Variables in text. Empty variables in will display path to datasource. #754
   fe-v4 kind/breaking-change kind/bug org/dsb org/ssb +5
2. Form element: Generic button #133
   area/validation fe-v4 kind/product-feature kind/user-story org/brg org/digdir org/krt org/mat org/pat org/ssb top10 +11
   
3. Validering ved hjelp av dynamikk #726
   area/logic fe-v4 feature-complete kind/feature-request org/ssb +5
   
4. Rewrite useGetOptions() and data lists to hooks using Tanstack Query without Redux #1294
   fe-v4 quality/debt +2
   

   
5. Replace Sagas with Tanstack Query #1094
   9 of 9
   Epic fe-v4 +2

[olemartinorg]

I'm also throwing #220 in here. I'm starting to look at bringing this type of functionality (expressions in layout, specifically) into some parts of the frontend in #355 now, but the way we prototyped in #220 meant it would be a breaking change.

[olemartinorg]

Adding a few more issues. Right now it's possible to define a filter for a group component, which can be used to filter out certain rows if they match a value in the data model. It is also possible to define a start/stop index. Showing/hiding rows should use proper dynamics instead, preferably by extending expressions.

[bjosttveit]

Filters on repeating groups appear to be somewhat broken, they currently do not function the way the documentation specifies.

1. If using more than one filter, only the last filter is actually applied. The documentation says that each element needs to satisfy all filters to be included.
2. If no elements satisfy the filters, all elements are still included.
3. The documentation states that "If there is only one result, this is displayed automatically in editing-mode". This does not happen.

The behavior related to adding new elements is also kind of wonky. The add button is still present (unless manually turned off), but if you click it, it will try to add a new element in editing mode which will be immediately filtered out and is not visible at all. Also the add button disappears.

If you edit the field that is filtered on, and change it so that it no longer satisfies the filters, it will be immediately hidden while typing and is no longer possible to access. Maybe it should wait until you click "Save and close" before such a thing happens.

[xmrsa]

Dette forklarer problemene jeg opplevde i mitt skjema, jamfør Slack: https://altinn.slack.com/archives/C02EVE4RU82/p1666346435963569

[StianVestli]

org/ssb

[olemartinorg]

@StianVestli Jeg dropper å tagge dere på dette issuet, siden det bare er en samling av ting vi bør tenke på til neste major-versjon (og dermed er ikke dette noe vi skal "gjøre") - vi kan heller tagge dere på de spesifikke sakene.

[olemartinorg]

Yet another challenge.. Currently we have useDelayedSaveState set up to handle delayed saving of the form (for when you're typing something and we don't want to save that to the server immediately for every keypress). While that's fine for text inputs, parts of it breaks when using it in checkboxes. The problem there is that checking a checkbox and then very quickly checking the next one might cause slowness from the first check to overwrite the second.

This can be reproduced by opening CheckboxesContainerComponent.tsx and setting the delay from 200ms to 800ms, then running the summary.js Cypress test.

We should consider fixing this by introducing a delayed saving saga instead - where all form changes should be batched up so we're not saving every time there is a change/blur. This might require breaking changes around the headers we pass to the backend detailing which component triggered a change - we should look into doing a full diff of the data model instead, and pass that info to the backend.

[olemartinorg]

Now that dynamics can hide entire pages, the PageOrder functionality seems to just create trouble for us, so we should consider removing it (and the calculatePageOrder trigger) to simplify page navigation. Using that in combination with expressions have proven to be problematic.

Read more about this:

• https://docs.altinn.studio/nb/app/development/logic/expressions/#viseskjule-hele-sider
• Unable to add text from ui-editor, text is not saved to text-file altinn-studio#712
• UI-editor: Better placeholder text in API-connection altinn-studio#713
• Add a dummy designsystem altinn-studio#718
• Repeating UI-container is buggy altinn-studio#657

[StianVestli]

Skeptisk til at man vil fjerne pageorder funksjonaliteten, siden denne gir oss muligheten til å manipulere data, og gjøre større endringer , endre rekkefølge på sidene osv, det går ikke med ny dynamikk. Da er er det bedre å si at man ikke kan kombinere dynamisk skjuling og pageorder. Eller om man kan manipulere Hidden propertyen via c# koden i pageorder. Fordlene med dynamikken er at den gjenspeiles i summary, det gjør ikke pageorder.

[olemartinorg]

@StianVestli Vi bør ikke ha to måter å gjøre det samme på. Den eneste fordelen jeg har sett med PageOrder er endring av rekkefølge, og potensielt det faktum at man må styre når det trigges (slik at man f.eks. kan skjule siden man står på i det øyeblikket man går til neste). Rekkefølge tenker jeg vi kan styre på andre måter. I dag finnes det opsjoner man kan sette på en layout som styrer hva som skal være neste og forrige side fra der man står, og i fremtiden tenker jeg det bør kunne styres med dynamikk. Uansett, litt av tanken med neste major-versjon er at vi rydder opp i eget hus - og det inkluderer å fjerne kode istedenfor å ha "både og"-funksjonalitet slik som dette.

Viktigst av alt: Om vi ikke får på plass alternativer som dekker alle eksisterende use-case kan vi naturligvis heller ikke fjerne funksjonalitet, nei.

[olemartinorg]

Work has now started, and the changes are currently kept in the next branch.

[bjosttveit]

Another consideration.

I think the "Group" concept should be more general, and that perhaps there should be several components that can have child components. For example, there could be an abstract subclass that all such components implement, that will be used to build the node hierarchy. Today, the Group type is hardcoded as the only such component.

With this in mind, I would like to see the current Group component split into several separate components. Today, the Group component is rendered using three different React components depending on some props:

1. Repeating group: if maxCount > 1.
2. PanelGroupContainer: if panel is not null/undefined. Used for adding new elements to another repeating group with a groupReference, or simply as a group with a background color if no groupReference is specified.
3. DisplayGroupContainer: otherwise. Plain old group with an optional title, makes it easier to create a Summary of a collection of components if fine grained control is not necessary.

To make this work, there is a GroupRendererer component that uses the appropriate react component depending on the props, this logic also needs to be implemented separately in the SummaryComponent. This is not currently implemented for the panel case, and will probably just be rendered the same way as a plain group.

This makes the Group component needlessly complex, and a lot of logic to check the type of Group component is required in many different places to make sure it behaves as expected. This all needs to be maintained during refactoring to make sure no weird use cases break. I think it is a bad idea to keep extending this component and increasing its complexity as opposed to creating several "Grouping" components with a more specific purpose for each.

Therefore, in a new major version, I would like to split the Group component into for example:

• RepeatingGroup
• Group (plain group, maybe with options for styling as a panel)
• Some third component to deal with the use case of adding data to another repeating group (please suggest an appropriate name)

This could be implemented in a way that most of the logic reside within the component classes, so that they are responsible for building and maintaining their sub-trees in the hierarchy. Maybe with common interfaces for getting all of their children and performing validations against their children.

[olemartinorg]

Another task we should consider:

• Define how groups and repeating groups should handle titles #820

There might also be more issues with possible breaking changes regarding design, and I think it would serve us well to go over the current app configuration and think through if we want to do some things differently in v4.

[olemartinorg]

Re: #1449, we should also make sure to detect the backend version and deny running on older/legacy backend versions. I'm hoping we can check for multipart-saving support on the backend for this, if that gets implemented on the backend any time soon - otherwise have have no reliable way of checking.