feat(nve-layout): layoutkomponenter

[malingranlynve]

Layoutkomponenter: stack, box, cluster og grid

Vi har til nå manglet layout i designsystemet, og endt opp med egendefinert css for layouts i hvert enkelt prosjekt. Denne PRen introduserer fire layout-primitiver som dekker det meste av hverdagsbehov. Layout-primitivene er basert på Every-Layout: https://every-layout.dev/

Hva er med?

stack-layout – stabler innhold vertikalt med mellomrom.

box-layout – pakker inn innhold med padding og valgfri bakgrunnsfarge.

cluster-layout – grupperer elementer horisontalt med automatisk linjebryting.

grid-layout – responsivt rutenett som tilpasser antall kolonner etter tilgjengelig plass, helt uten media query.

Alle komponentene bruker samme mønster: en size-prop som er låst til spacing-tokenene våre og en separat gap/padding-prop for rå CSS-verdier i unntakstilfeller.

Hva er ikke med?

Det ble vurdert å ta med: center-layout, columnist-layout, cover-layout, sidebar-layout og wrapper-layout, men jeg landet på at det er bedre å legge til når vi ser behovet kommer. Jeg tror det meste av bruk er dekket godt med de som tilbys nå.

Si gjerne ifra om du vil endre på noe!

fixes #898

[lisamarimyreneNVE]

Du har sikkert tenkt på dette, men burde det heller hete nve-box, nve-layout, nve-stack osv. for å lettere se i koden at det kommer fra nve designsystemet og ikke noe "egendefinert"? Er usikker på hva som er best, kanskje flere har noen meninger på det?

[malingranlynve]

Du har sikkert tenkt på dette, men burde det heller hete nve-box, nve-layout, nve-stack osv. for å lettere se i koden at det kommer fra nve designsystemet og ikke noe "egendefinert"? Er usikker på hva som er best, kanskje flere har noen meninger på det?

Jeg lurte på det samme! Ser også at f.eks. aksel.nav.no bruker bare "box" og "stack", så jeg er usikker på hva som er best her

[gruble]

Bra jobba med dokumentsjon og gode eksempler.
Jeg liker at komponentene er basert på tanker og problemstillinger som er kjent og godt dokumentert fra før (på https://every-layout.dev/).

Vi får noen pedagogiske utfordringer fordi vi bruker size for å sette gap og padding. Likevel tilbyr vi overstyring ved å sette gap, padding direkte. Dette synes jeg er litt forvirrende. Kan vi ende opp med at noen angir gap eller padding med token-verdier i stedet for å bruke size og er dette egentlig et problem?

Jeg må innrømme at jeg falt av ganske fort da jeg forsøkte å lese de eksemplene som var tilgjengelige på https://every-layout.dev/
Er det virkelig så komplisert å lage god responsiv layout?

Jeg driver fortsatt og lærer meg CSS og det er mye jeg ikke skjønner.
Men jeg har stort sett greid å få til den layouten jeg ønsker med å bruke CSS likevel.
Trenger vi da et ekstra lag oppå CSS for å håndtere layout?

Hvis vi velger å ta i bruk egne komponenter for layout i designsystemet, ønsker jeg at vi dokumenetrer fordeler og ulemper med dette i https://github.com/NVE/Designsystem/blob/main/beslutninger.md og hvorfor vi bestemmer oss for å bruke dem. Kanskje bør vi skrive noe her uansett om vi går for det eller ikke, så slipper vi omkamper:)

[olmabo]

Veldig kult at dere ser på slike komponenter, og bra docs og oppsett ! Jeg har ikke sett så nøye på alt men legger bare inn noen punkter her jeg kommer på etter en rask titt:

• Kunne size i box-layout egentlig heller hete padding? For det er vel padding som egentlig settes basert på den. Ofte har man bruk for padding/margin som er ulike horisonalt og vertikalt. Av og til trenger man også ulike padding i top/bottom og left/right. Så tror det også kunne vært lurt å hatt blant annet disse props-ene:
  • margin/padding
  • paddingBlock/paddingInline
  • marginBlock/marginInline
• Kunne alle layout-komponentene hatt/arvet en del felles props? Feks kunne alle layout-komponentene arvet margin/padding props (og flex-props også evt). Ofte vil man feks sette en stack med en gap, men man vil kanskje ha litt padding/margin også. Da slipper man lage 2 html-elementer (1 box og en stack). Box kan fungere som en base-komponent for de enkleste tingen som padding/margin osv, mens grid og stack har litt ekstra props som er rettet mot grid (kolonner) og stack (gaps)
• hadde det vært mulig med egen mappe til layout-komponenter i src/components ? Under doc-site har dere doc-site/layout som jeg synes er fint og ryddig. Tror det kunne vært fint med feks src/components/layout eller lignende også. Da kunne man også hatt noe kode som var felles for alle layout-kompoentene der

[amish1188]

Du har sikkert tenkt på dette, men burde det heller hete nve-box, nve-layout, nve-stack osv. for å lettere se i koden at det kommer fra nve designsystemet og ikke noe "egendefinert"? Er usikker på hva som er best, kanskje flere har noen meninger på det?

Jeg lurte på det samme! Ser også at f.eks. aksel.nav.no bruker bare "box" og "stack", så jeg er usikker på hva som er best her

Det er fordi aksel lager ikke web komponenter, men react komponenter så de trenger ikke å bruke prefixer :).

Vi bruker prefixer på alle komponentene våre, så ja, enig med Lisa. Vi bør ha nve- prefix på alle disse her ellers må man skrive en ekstra konfig i vue eller react applikasjoner slik at de skjønner hva "box-layout"-html element betyr. I dag sørger vi det det fungerer på alle nve- komponenter med (eksempel fra vue):

export default defineConfig({
  plugins: [
    vue({
      template: {
        compilerOptions: {
          isCustomElement: (tag) => tag.includes('nve-'),
        },
      },
    }),
  ],
});

[amish1188]

Jeg stemmer for å slå sammen Stack og Cluster. Den eneste forskjellen mellom dem virker å være retningen, så vi kunne hatt én komponent med en orientation-property som styrer om elementene legges vertikalt eller horisontalt. Færre komponenter er enklere å vedlikeholde tenker jeg ;)

[malingranlynve]

Jeg tror det kan være hensiktsmessig å beholde disse som to forskjellige komponenter. Noe av fordelen med å ha de separat er at vi får mindre komponenter som gjør spesifikke ting i stedet for komponenter som gjør mye og fort kan bli bloated hvis behov endrer seg.

Jeg tror også at det semantiske er noe vi må se på. En Cluster forteller utvikleren med en gang at noe skal legges horisontalt, samme med Stack og vertikalt. Har vi bare en Stack med orientation-props er det ikke like intuitivt for utvikleren å se hva som skjer, og vi åpner for mange flere kombinasjoner av props, noe som kan føre til at det blir inkonsistent bruk på tvers av prosjektene.

Har dere noen tanker om dette, @lisamarimyreneNVE, @gruble, @olmabo?

[lisamarimyreneNVE]

Siden det allerede er etablerte pattern på de forskjellige, gir det kanskje mest mening å ha de separat for å følge en mest mulig standard.

[amish1188]

Jeg ser poenget ditt, men jeg er ikke enig fortsatt (sorry).

For meg betyr Cluster at flere ting er gruppert eller samlet på ett sted. Jeg ville aldri automatisk tolket at "Cluster" betyr et horisontalt layout. Derimot er Stack et mønster som brukes i mange store komponentbiblioteker, hvor orientering (vertikal eller horisontal) styres med en orientation- eller direction-prop.

Slik jeg ser det, er det kun flex-orientation som skiller disse to komponentene. Det føles derfor unødvendig å vedlikeholde to nesten identiske komponenter når forskjellen er så liten. Med én komponent blir det mindre kode å vedlikeholde og færre steder som må oppdateres dersom vi ønsker å endre funksjonalitet eller API senere.

Vil gjerne høre fra andre og.

[amish1188]

Jeg ser at aksel bruker HStack og VStack. Syns kanskje det virker mer intuitivt enn Cluster og Stack når vi snakker om retningen.

[amish1188]

En annen ting er at vi allerede bruker begrepet Cluster i kartløsningene våre, hvor flere markører eller punkter slås sammen til én representasjon. Der beskriver navnet veldig godt hva komponenten gjør – den grupperer elementer og viser brukeren at det finnes flere objekter under én markør (dette er en global standard for å kalle den slik).

Derfor synes jeg det kan bli litt navn konflikter her. Det kan fort skape misforståelser både i kodebasen og for utviklere som er nye i prosjektet.

Av den grunn mener jeg at en generell Stack med en orientation-prop er et mer naturlig og gjenkjennelig API, samtidig som vi unngår navnekonflikter med kartkomponentene våre. Evt StackHorizotnal eller noe lignende som Aksel gjor.

[malingranlynve]

Jeg er helt enig i at Cluster betyr at ting er gruppert, og det er på en måte akkurat det jeg vil frem til! Cluster (i layout-sammenheng) betyr at elementer er gruppert og oppfører seg på en klyngemåte med wrapping. Derfor synes jeg navnet passer godt ettersom det beskriver akkurat det komponenten gjør. Cluster er også et veletablert begrep som baserer seg på Every Layout.

Teknisk sett er forskjellen liten, men konseptene er veldig forskjellige. En Stack representerer en lineær layout, mens Cluster handler om gruppering og wrapping. Derfor synes jeg ikke HStack og VStack gir like mye mening konseptuelt.

Når det gjelder navnet Cluster så skjønner jeg hva du sier om at vi allerede bruker det i kartløsningene våre. Samtidig beskriver begge tilfellene egentlig den samme tanken om at elementer grupperes og presenteres som en enhet. Derfor ser jeg på det mer som konsistent begrepsbruk heller enn en navnekonflikt. Siden kart-clustering og layout-clustering brukes i ulike kontekster tror jeg ikke det vil skape forvirring.

Men jeg er veldig åpen for flere meninger om dette! @gruble, @olmabo?

[amish1188]

Jeg er ikke kjent med Every Layout men ser min guru Kevin Powell anbefaler den. Jeg har sjekket ut deres forslag for layout. Jeg synes egentlig at Cluster er en god abstraksjon dersom vi følger Every Layout-filosofien mer helhetlig. Men siden vi bevisst har valgt å forenkle API-et til kun noen layout-komponenter, ender Cluster opp med å representere én veldig spesifikk horisontal oppførsel (med wrapping).

Vi får andre behov for horisontal layout når man f.eks ønsker å overflyte elementer i stedet for å wrappe. Da vil cluster ikke fungere her bra fra begrepsperspektivet fordi cluster skal wrappes. Betyr det at vi trenger en ekstra komponent til å dekke dette behovet (som Reel)? Eller så virker det at vi har noen ide her på hvordan vi skal lage layout komponenter men den er ikke helt der.

Så kanskje vi bør vurdere om vi skal gå å bruke Every Layout forslag helhetelig eller bare fokusere på noen små komponenter der hvor Cluster kanskje ikke er et bra valg. Der vil jeg fortsette med Stack V og H.

Vi kunne evt ha Box, Stack, Cluster, Reel, Grid i utgangspunktet og så vurdere Center senere f.eks?

[amish1188]

her er forresten en lenke til Every Layout

[amish1188]

(det er en veldig bra diskusjon @malingranlynve 👏)

[amish1188]

• hadde det vært mulig med egen mappe til layout-komponenter i src/components ? Under doc-site har dere doc-site/layout som jeg synes er fint og ryddig. Tror det kunne vært fint med feks src/components/layout eller lignende også. Da kunne man også hatt noe kode som var felles for alle layout-kompoentene der

Ja det er mulig det :)

[github-actions]

Azure Static Web Apps: Your stage site is ready! Visit it here: https://brave-meadow-0c645bd03-907.westeurope.5.azurestaticapps.net