Skip to content

Commit 5c0515d

Browse files
docs(design-beslutninger.md): Oppdatert beslutning for versjonering på pakkenivå (#734)
* docs(design-beslutninger.md): Oppdatert beslutning for versjoner på pakkenivå
1 parent 9635a75 commit 5c0515d

1 file changed

Lines changed: 27 additions & 15 deletions

File tree

design-beslutninger.md

Lines changed: 27 additions & 15 deletions
Original file line numberDiff line numberDiff line change
@@ -1,10 +1,35 @@
1-
# Design-beslutninger
1+
# 🎨 Designbeslutninger
22

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.
44
Vi skriver også om hvilke alternativer som ble vurdert og hvorfor enkelte alternativer ikke nådde opp.
55

66
Vi sorterer valgene etter tidspunkt for når de ble gjort, med de siste valgene øverst.
77

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+
833
## Ny dokumentasjons-løsning (juli 2024)
934

1035
Dokumentasjon var tidligere på tre forskjellige steder:
@@ -65,16 +90,3 @@ TODO: Skriv hvorfor vi valgte dette
6590
## Eget designsystem eller ikke? (når bestemte vi dette?)
6691

6792
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

Comments
 (0)