LobaDK
commented
3 weeks ago Efter diskussion har vi konkludere at ekstra data i form af en model fra backenden er påkravet. Modellens formål ville være at definerer validation krav på hver indstilling, og andet metadata.
API'en ville blive ændret til at sende en respons hvor både indstillingerne og modelen er inkluderet. For hver indstilling dashboardet går igennem, vil der være en attribute med et matchende navn i modellen, som den kan referere til.
Forslåelse
Hver indstilling i modellen er et Metadata object som indeholder 6 værdier:
default: string, number, boolean, array = null. Default værdien på indstillingen. Hvis ikke defineret, kan indstillingen starte om tom, f.eks. efter første installation.- minValue:
number= null. Minimum værdien på indstillingen, hvis defineret. - maxValue:
number= null. Maximum værdien på indstillingen, hvis defineret. - allowedValues:
array= null. Et array af værdier som indstillgen tillader, hvis defineret. - canBeEmpty:
boolean= null. Kontrollerer om indstillingen må være tom når brugeren trykker gem. - description:
string= null. En eventuel beskrivelse af hvilket formål indstillingen har, hvis defineret.
Dashboardet kan så bruge dette metadata til at tilføje de påkrævet validators, og styre hvordan hvert field skal se ud, inklusivt om det skal være en radio knap (typen af indstillingen er boolean), drop-down liste (allowedValues er defineret), etc.)
@maxumi
Ligesom #4 ville det være optimalt hvis dashboardet kunne dynamisk lave input fields til de indstillinger den får af backenden.
Som det er nu, skal der manuelt laves nye input fields til hvert indstilling. Problemet er at instillingerne kan hurtigt ændres igennem opdateringer, hvor der tilføjes eller ændres i deres navne.
Backenden inkludere allerede navne samt hele strukturet på indstillingerne, så ingen ektra API kald burde være påkrævet.