Behov for visning av informasjon fra datamodellen

[lillelars]

OED har et behov for å kunne vise informasjon fra ulike datamodeller. Eksempel:
https://digdir.apps.tt02.altinn.no/digdir/oed-svv#/instance/50002123/6fc94e36-ecb7-421f-8c0b-77ec153ed164
(P.S. Har forsøkt å beskrive en av komponent-behovene her:
#293 )

Vi ønsker dette:

T3.0 har dette:

Her har vi forsøkt å vise data fra modellen på en pen måte.

Behovet til OED er å kunne gjøre tilsvarende på flere ulike applikasjoner, uten å måtte oppdatere hver enkelt applikasjon dersom T.30 oppdaterer sine komponenter.

Vi ser for oss en løsning der vi kan "velge og vrake" fra et større GUI-komponent-bibliotek, men dersom selve komponenten ikke finnes i biblioteket har vi behov for å utvikle den selv i samme applikasjon. Per nå får vi et forvaltningsproblem ettersom vi passe på at hver applikasjon har oppdaterte komponenter.

Videre ser vi for oss at OED kan være med å utvide dette komponent-biblioteket, der ressurser fra T3.0 godkjenner de komponentene vi lager før de blir en del av biblioteket. (Per nå har vi utviklet en del komponenter som vi ønsker å foreslå inn til dette biblioteket, hvis ønskelig).

Eksempelvis: En penere tabellvisning av informasjonen fra SVV-modellen i eksempelet over.

Mål: automatisk oppdatering av fremtidige endringer i standard GUI (komponentene) skal følge med til de ulike custom-GUI'ene som benytter disse standardkomponentene.

Delmål:

• skal ikke miste tilgang på T3.0 komponenter
• skal få automatisk oppdateringer på frontendrammeverk
• skal få oppdateringer gjort av utviklere på T3.0 tilknyttet frontend prosjektet:
  https://github.com/Altinn/altinn-studio/tree/master/src/Altinn.Apps/AppFrontend/react/altinn-app-frontend

Eksempel 2:

• Ser for oss at vi kan f.eks velge å benytte "Header" + "Footer" + "Title" + "Datepicker", og utvikle resten av GUI-laget selv.

What needs to be solved?

How do you want it solved?

Alternative solutions

Additional context

[lillelars]

nb! Legg til label org/digdir for å koble dette mot OED

[altinnadmin]

@lillelars

OED har et behov for å kunne vise informasjon fra ulike datamodeller. Eksempel:

Kan du lime inn skjermdump under lenken over, slik at alle som ikke tilgang til denne instansen også kan se det du refererer til?

Mål: automatisk oppdatering av fremtidige endringer i standard GUI (komponentene)

Dette er jo "defaultmodellen" for apps i Altinn 3, så her må vi finne ut hva OED har gjort som forhindrer dette. Antar at dere kanskje bare har kopiert inn altinn-app-frontend lokalt?

Ser for oss at vi kan f.eks velge å benytte "Header" + "Footer" + "Title" + "Datepicker", og utvikle resten av GUI-laget selv.

Her bør vi nok også se på hva som skal til for å unngå egenutvikling, noe som bør være et mål for både OED og Altinn 3. Vi ønsker ikke å måtte forvalte custom GUI for OED.

[lillelars]

@lillelars

OED har et behov for å kunne vise informasjon fra ulike datamodeller. Eksempel:

Kan du lime inn skjermdump under lenken over, slik at alle som ikke tilgang til denne instansen også kan se det du refererer til?

Done

Mål: automatisk oppdatering av fremtidige endringer i standard GUI (komponentene)

Dette er jo "defaultmodellen" for apps i Altinn 3, så her må vi finne ut hva OED har gjort som forhindrer dette. Antar at dere kanskje bare har kopiert inn altinn-app-frontend lokalt?

Mulig vi trenger en gjennomgang her ja

Ser for oss at vi kan f.eks velge å benytte "Header" + "Footer" + "Title" + "Datepicker", og utvikle resten av GUI-laget selv.

Her bør vi nok også se på hva som skal til for å unngå egenutvikling, noe som bør være et mål for både OED og Altinn 3. Vi ønsker ikke å måtte forvalte custom GUI for OED.

Yes - enig i dette, men da er vi på løsning. Har tatt en prat med rune og Steffen og ble enig om å registrere ulike komponent-behov hver for seg

[altinnadmin]

Ok, skjermdumpene der virker å være info fra samme repeterende datamodell, ikke ulike datamodeller, og det håndteres da i #293.

Så for meg så virker det som gjenstår i denne issuen da er å finne ut hvordan man også i OED kan få til å gjenbruke komponenter direkte uten "copy&paste"?

Komponenter som OED har laget, som man ønsker å få inn i felles bibliotek antar jeg bør være egne issues.

[lillelars]

Jeg merker jeg sliter litt med å forklare meg her - kanskje vi kan ta 5 min på teams så jeg får forklart hva jeg tenkte?

Behovet er at vi trenger alternative eller bedre visningskomponenter for ulik type data vi ønsker å vise.
Eksempler er:

• alternativ visning repeterende liste
• alternativ visning på eksterne lenker (men skal føles for en bruker at han/hun benytter samme løsning)
• Visning på introduksjonsmelding før tjeneste
  ... jeg kan remse opp en del andre eksempler også.

Dersom det hadde vært et uendelig stort bibliotek der vi bare kunne plukket komponenter så har vi det vi trenger. Men inntil det er på plass trenger vi å bruke noen av komponentene som finnes, samtidig som at vi utvikler resten på egen hånd.

Per nå må vi kopiere over de komponentene som finnes. Da mister vi eventuelle oppdateringer som blir gjort av T3.0 teamet. Dette er uheldig når vi på sikt kommer til å ha 4-5 ulike tjenester som alle vil være avhengig av å benytte komponenter fra T3.0.

[altinnadmin]

Jeg merker jeg sliter litt med å forklare meg her

Tror ønsket er ganske klart.

Men inntil det er på plass trenger vi å bruke noen av komponentene som finnes, samtidig som at vi utvikler resten på egen hånd.

Er kanskje "resten" som er mest interessant. Er du sikker på at det ikke er potensiale for gjenbruk også der? Tenker jo at det å gjøre komponenter mer fleksible (bedre) er fornuftig, og noe vi alle ønsker å få til. Der er repeterende lister, eksterne lenker, etc eksempler.

Per nå må vi kopiere over de komponentene som finnes.

Og der tror jeg vi er ved kjernen i hva akkurat denne issuen bør være og fokusere på? Hvordan vi kan unngå denne kopieringen?

[ivarne]

Å lage generiske komponenter for gjenbruk er ca 100 ganger mer job enn å lage en spesialkomponent som gjør en job. Det finnes også enormt med muligheter for gjenbruk av react funksjonalitet utenfor den lille verden vi kaller altinn.

Å endre en standardkomponent som skal fortsette å være bakoverkompatibel med annen bruk er alltid mye vanskeligere enn å skrive en ny. Det jeg kan se for meg at jeg (og mange med meg) ønsker, er at alternaltiv til utvalget med standardkomponenter for altinn. Å vente flere måneder på feedback og "kan vi ikke kanskje se dette i en større sammenheng" er helt meningsløst når man har sagt man skal løse et problem på en måned. Så kan altinn gå og se på hva som utvikles av slike ekstrakomponenter og vurdere om kvaliteten er god nok, og nytten er stor nok til at de bør pyntes litt på og inkluderes som en offisiell komponent.

[altinnadmin]

Yup, det er akkurat disse tingene jeg tenker vi må få litt mer fokus på nå fremover.

• Hvordan kunne gjenbruke det man ønsker av "Altinn-komponenter" uten å måtte kopiere og ta eierskap til dem selv (denne issuen)
• Hvordan kunne ta i bruk egenutviklede komponenter eller noe andre har utviklet (react-økosystemet) på en enkel og sikker måte.
• Hvordan gjøre komponentene og app-GUI generelt mye mer fleksibelt slik at de kan dekke langt flere behov (slik som f.eks. "dashboard" i OED).

[olemartinorg]

Vi kommer kanskje enda litt lengre med denne:

• New component: Grid #583

Spesifikt om man putter en Grid-komponent som eneste barn av en repeterende gruppe, og setter på "mode": "showAll" på rep.gruppa.