|
1 | | -# Design-beslutninger |
| 1 | +# 🎨 Designbeslutninger |
2 | 2 |
|
3 | | -Hensikten med denne sida er å dokumentere hvilke større valg vi har gjort for komponentbiblioteket og _hvorfor_ vi har tatt akkurat de valgene. |
| 3 | +Hensikten med denne siden er å dokumentere hvilke større valg vi har gjort for komponentbiblioteket og _hvorfor_ vi har tatt akkurat de valgene. |
4 | 4 | Vi skriver også om hvilke alternativer som ble vurdert og hvorfor enkelte alternativer ikke nådde opp. |
5 | 5 |
|
6 | 6 | Vi sorterer valgene etter tidspunkt for når de ble gjort, med de siste valgene øverst. |
7 | 7 |
|
| 8 | +## Versjonering på pakkenivå fremfor komponentnivå (desember 2025) |
| 9 | + |
| 10 | +Versjonering på komponentnivå ville tillatt team å oppdatere kun de komponentene de trenger uten å måtte ta inn hele pakken. Dette kan virke attraktivt, men skaper flere utfordringer enn fordeler. |
| 11 | + |
| 12 | +Hovedproblemet er kompleksiteten med vedlikehold. Å håndtere versjonering for hver enkelt komponent ville blitt mye mer arbeidskrevende og tidskrevende enn vi har kapasitet til, siden vi må oppdatere og vedlikeholde hvert komponent separat. Dette kan også føre til kompatibilitetsproblemer når forskjellige versjoner av komponenter kommer i konflikt med hverandre, spesielt siden de deler designtokens og grunnleggende styling. |
| 13 | + |
| 14 | +En annen utfordring er at team som bruker forskjellige versjoner av komponenter risikerer at designet blir inkonsistent på tvers av applikasjonene. Når det ikke lenger er press på å oppdatere hele pakken, reduseres også motivasjonen for å holde komponentene oppdatert, noe som fører til teknisk gjeld. |
| 15 | + |
| 16 | +Figma setter også naturlige begrensninger i og med at man ikke kan versjonere på enkeltsider eller enkeltkomponenter, men må versjonere på hele designsystemet. Endrer man én komponent må det lages ny versjon av alt. |
| 17 | + |
| 18 | +Etter diskusjon ble det bestemt at vi fortsetter med versjonering på pakkenivå. Dette er i tråd med hvordan de fleste andre designsystem håndterer versjonering. |
| 19 | + |
| 20 | +## Felleskomponent for filopplasting |
| 21 | + |
| 22 | +Vi valgte å ikke lage en felles filopplasting-komponent i designsystemet på grunn av kompleksiteten og de forskjellige behovene teamene har. |
| 23 | + |
| 24 | +En slik komponent ville hovedsakelig være en wrapper rundt en input med `type="file"`. Utfordringen ligger ikke i selve UI-en, men i all logikken som må håndteres etter at filer er valgt: |
| 25 | + |
| 26 | +- Validering (filtype, størrelse, antall filer) |
| 27 | +- Opplasting til forskjellige endepunkter |
| 28 | +- Progresjonsvisning og feilhåndtering |
| 29 | +- Forskjellige krav til metadata og beskrivelser |
| 30 | + |
| 31 | +Siden hver applikasjon og team har unike krav til disse aspektene, bestemte vi at teamene selv implementerer filopplasting-funksjonaliteten tilpasset sine behov, fremfor å lage en generisk komponent som ville blitt for kompleks eller for begrenset. Designet skal likevel være likt på tvers av applikasjonene. |
| 32 | + |
8 | 33 | ## Ny dokumentasjons-løsning (juli 2024) |
9 | 34 |
|
10 | 35 | Dokumentasjon var tidligere på tre forskjellige steder: |
@@ -65,16 +90,3 @@ TODO: Skriv hvorfor vi valgte dette |
65 | 90 | ## Eget designsystem eller ikke? (når bestemte vi dette?) |
66 | 91 |
|
67 | 92 | TODO: Skriv hvorfor vi valgte dette |
68 | | - |
69 | | -## Felleskomponent for filopplasting |
70 | | - |
71 | | -Vi valgte å ikke lage en felles filopplasting-komponent i designsystemet på grunn av kompleksiteten og de forskjellige behovene teamene har. |
72 | | - |
73 | | -En slik komponent ville hovedsakelig være en wrapper rundt en input med `type="file"`. Utfordringen ligger ikke i selve UI-en, men i all logikken som må håndteres etter at filer er valgt: |
74 | | - |
75 | | -- Validering (filtype, størrelse, antall filer) |
76 | | -- Opplasting til forskjellige endepunkter |
77 | | -- Progresjonsvisning og feilhåndtering |
78 | | -- Forskjellige krav til metadata og beskrivelser |
79 | | - |
80 | | -Siden hver applikasjon og team har unike krav til disse aspektene, bestemte vi at teamene selv implementerer filopplasting-funksjonaliteten tilpasset sine behov, fremfor å lage en generisk komponent som ville blitt for kompleks eller for begrenset. Designet skal likevel være likt på tvers av applikasjonene. |
|
0 commit comments