Repeating groups: Open by default blir feil ved bruk av hiddenRow

[StianVestli]

Description of the bug

Open by default funker ikke som det skal hvis man setter hiddenRow regel slik at første raden i gruppen er filtert vekk.

Steps To Reproduce

se over.

Additional Information

Blocked by: #1175

[StianVestli]

org/ssb

[lassopicasso]

Bra catch @StianVestli. Kunne du delt link til appen som brukes her? :)

[StianVestli]

https://altinn.studio/repos/stian.vestli/ra0244-01.git commit d2f4511806fa9a37954122d0a80a05854e067bb2

[olemartinorg]

Jeg og @lassopicasso snakket litt om denne i dag, og hvordan man burde gått frem for å løse dette. Akkurat nå ligger to av tilstandene (index, som sier hvor mange rader det finnes, og editIndex som sier hvilken av dem som skal redigeres) utenfor selve gruppa (i et delt tilstandslager), og med litt blanding av hvor slike tilstander ligger (på komponenten eller i delt lager/redux) blir det kanskje litt fort krøll. Uten gode verktøy blir det altså litt fort gjort å prøve å sette rad 0 som åpen for redigering uten å sjekke først om rad 0 faktisk er synlig. Så jeg tenker dette er noe vi bør fikse i en større kontekst, med litt refaktorering av denne tilstanden.

I appen jeg laget for testing av Grid og komponenter-i-tabell er dette ekstra tydelig, da jeg bruker samme repeterende struktur fra datamodellen på flere Group-komponenter. Da skjer det mye rart, som f.eks:

1. Sletting av en rad i en gruppe fører ikke til at den samme raden blir sletta i de andre gruppene (fordi den eksterne index ikke blir oppdatert, selv om den burde være en følge av tilstanden som ligger i datamodellen).
2. Hvis man legger til 3 nye rader (uten å legge til data i dem), og begynner å legge til data i den midterste av dem fant jeg to problemer:
   • Den siste raden forsvant plutselig. Jeg fikk fiksa dette for tilfeller når man ikke gjør endringer i gruppa i ProcessDataWrite, men når vi får tilbake nye data i gruppa er det vanskelig å fikse dette uten å først ha sendt en tom rad til server for den siste raden (se Validation trigger on group should re-validate on delete + new row #555)
   • Den første raden, som er tom, blir til null når vi sender over data til server. Hvis server ikke er forberedt på at en tom rad kan være null får man fort en kjøretidsfeil i C# og appen kræsjer.

Dette bør altså ryddes og forenkles, og jeg tror først når det er ryddet opp her blir det enkelt å lage openByDefault som faktisk fungerer godt sammen med skjulte rader. Det samme gjelder nok også #1111.