Closed kluvin closed 1 month ago
Jeg fikset ett problem med at det ikke ville loade.
Drink fra $lib/Drink.svelte fantes ikke, hvis noen vi lage denne kan de.
Denne regelen skal garantere at
auth.user
ikke kan lese enorder_drink
som ikke er lagt til i user.favorites
Kunne du forklart hvordan systemet med favoritter og order_drink fungerer? Jeg forstår ikke helt hva du mente med det
Jeg synes også at kanskje dette burde være en annen route enn /
, heller noe som /menu
? Vi burde kanskje hatt noe litt annet enn å gå direkte til menyen, for eksempel som i #20
@LilleAila beklager, jeg så ikke bilde i den PRn!
Jeg tenker jo det absolutt første en bruker vil gjøre den første, andre, og tredje gangen de går inn på siden er å bestille, med minst mulig klikk. Jeg tenker så lite som to-tre klikk for 80% av bestillinger, dvs i stor grad de uten ekstravalg (men selv her kan favoritter brukes).
Hva er formålet med å ha reviews på forsiden, og hvordan tjener dette brukeropplevelsen?
Jeg ville nedprioritert reviews, kaffe-diem har alt et etablert rykte som er positivt, og er i grunn og bunn et statlig eid monopol.
Kunne du forklart hvordan systemet med favoritter og order_drink fungerer? Jeg forstår ikke helt hva du mente med det
Se kun på order_drink
som er en sammling hvilket inneholder unike "drinker" laget per bestilling. Disse er tilknyttet en ordre, som er tilknyttet en bruker. Derfor er en drink tilknyttet en bruker. Bare en bruker bør derfor ha tilgang til en vilkårlig drink.
Pocketbase har API regler for filtrering og adgangskontroll, disse må brukes, og vil representere en del av business logikken i systemet.
@LilleAila beklager, jeg så ikke bilde i den PRn!
Jeg tenker jo det absolutt første en bruker vil gjøre den første, andre, og tredje gangen de går inn på siden er å bestille, med minst mulig klikk. Jeg tenker så lite som to-tre klikk for 80% av bestillinger, dvs i stor grad de uten ekstravalg (men selv her kan favoritter brukes).
Hva er formålet med å ha reviews på forsiden, og hvordan tjener dette brukeropplevelsen?
Jeg ville nedprioritert reviews, kaffe-diem har alt et etablert rykte som er positivt, og er i grunn og bunn et statlig eid monopol.
Reviews er ikke viktig, jeg bare lagde en enkel versjon fordi jeg ville ha noe å fylle strtsiden med, så det er egentlig null grunn til å ha det på forsiden utenom å midlertidig fylle den med noe. Kanskje man heller kunne vist et utvalg fra menyen eller noe slikt?
vist et utvalg fra menyen eller noe slikt?
For å spille på dette kunne vi tagget noen ting som populære?
Kan vi eventuelt putte reviews som en karusell nederst på infoskjermen, som en slags motivator for å bestille?
I stedet for reviews, kan vi heller ha et slags messageboard som lar folk skrive hva enn de vil? Litt sånn hipster aktig. (jeg er klar over at noen vil skrive noe kødd, så i utgangspunktet er dette ikke superprioritert)
@CarlAugust tusen takk! du redda meg!
vist et utvalg fra menyen eller noe slikt?
For å spille på dette kunne vi tagget noen ting som populære?
Jeg tenker vi kan lage en form for dashboard for admins (de som jobber i kaffe diem), der de kan redigere kategorier, produkter og da også merke hva som skal vises på forsiden eller ikke. Da ville vi trengt noe som en boolean for hver user som sier om de er admin eller ikke, slik at de får tilgang til de sidene de trenger og har write-access i db ved hjelp av pb-regler.
vist et utvalg fra menyen eller noe slikt?
For å spille på dette kunne vi tagget noen ting som populære?
Har litt lyst å sortere menyen etter hva som har blitt kjøpt flest ganger. Da må vi lagre det som drink.timesBought eller noe, men det gjør populariteten dynamisk.
Formatert kode til å passe med #11. Flyttet /+page.svelte
til et annet sted, siden origin/main
har en annen route der. Kan endres til hvordan du synes det passer best.
@LilleAila
Intensjonen var å lagre favoritter og ordrehistorikk inntil i /account
som jeg for øvrig tolker som "min side", inntil videre, ettersom jeg ikke ser behov for å lage en rute for disse to.
Det er emne som kan tas opp i felleskap, derimot. Jeg ser grunn til å vise favoritter og historiske kjøp på bestillingssiden, som jeg hittil har sett for meg er /
.
Vi har all mulighet i verden til å gjøre mange dårlige valg i dag og fikse på dem i morgen. Inntil vi har diskutert disse tingene i plenum tenker jeg alt som er gjort er bedre enn det som er gjennomtenkt. Så jeg har ingen preferanse akkurat i dag.
@IldenH
Vi lagrer denne dataen i order_drinks
og kan kjøre aggregates på den, for å finne ut dette samt om for eksempel mocca blir solgt mer av på fredager, eller mandager. Hvis vi har 1 million records der tar en query for å samle data, så tar den forholdsvis veldig kort tid.
Inntil videre eksisterer ikke denne dataen, og så vil den være ustabil, så ser dette som en oppfordring til å hardkode i utgangspunktet.
Intensjonen var å lagre favoritter og ordrehistorikk inntil i
/account
som jeg for øvrig tolker som "min side", inntil videre, ettersom jeg ikke ser behov for å lage en rute for disse to.
Dette synes jeg passer, det var originalt dette jeg hadde tenkt den skulle brukes til.
Det er emne som kan tas opp i felleskap, derimot. Jeg ser grunn til å vise favoritter og historiske kjøp på bestillingssiden, som jeg hittil har sett for meg er
/
.Vi har all mulighet i verden til å gjøre mange dårlige valg i dag og fikse på dem i morgen.
Det er jeg enig i; jeg synes det passer med bestilling på /
, men flyttet den midlertidig for å unngå merge-konflikter når jeg merget main til denne branchen.
Mottatt. Vi kan flytte alt på sikt, rent organisasjonsmessig. Jeg vet ikke hvordan det vil se ut med reviews og det som er på forsiden nå. Jeg tenker denne PR er klar til merge, dog det gjenstår en del arbeid.
@LilleAila Jeg foreslår at vi fokuserer på alt av UI/UX samt a11y inntil vi har lansert den mest enkle og nødvendige funksjonaliteten.
Selv er jeg den mest pedantiske når det gjelder brukeropplevelser, men vi må ha fokus på en ting av gangen. Det er helt reelle odds for at jeg kaster vekk 90% av koden her neste uke.
Av ting som er nevnt, ser jeg kun behov for å fikse server loading, gitt vi har nå valgt å gjøre dette globalt, samt den 500 tingen du ser.
Hva tenker du?
Er tilfelle at vi kaster vekk 90% av koden hvis vi velger å bruke noe annet enn pocketbase?
Er tilfelle at vi kaster vekk 90% av koden hvis vi velger å bruke noe annet enn pocketbase?
Egentlig UI, men også pocketbase. Hvis vi kaster bort pocketbase, har vi lært hvordan datamodellen skal se ut via iterasjon gjennom pocketbase, og det er verdt det.
Det som er fint med pocketbase er at den bruker sqlite, som er portabelt.
Hvis man finner ut hvordan datamodellen skal se ut, vil algoritmene skrive seg selv. -paraphrase fra Programming Pearls
"Logg Ut" knappen bør være i "Min Bruker" menyen, istedenfor å være oppe i høyre hele tiden. I tillegg bør man kunne endre themet til nettsiden i "Min Bruker" menyen til enten lys, mørk eller følg systeminstillinger
"Logg Ut" knappen bør være i "Min Bruker" menyen, istedenfor å være oppe i høyre hele tiden. I tillegg bør man kunne endre themet til nettsiden i "Min Bruker" menyen til enten lys, mørk eller følg systeminstillinger
Bør nok gjøres i en annen PR.
Implementerte innhenting av bestilling' display (
/
)Implementerte favoritter som et slags testprosjekt for å finne ut hvordan man kun leser en enkelt brukers' items.
Denne PR gjør en del for mye. Jeg valgte å kombinere to ting siden begge rører
Drink
komponentet direkte.todo for favoritter:
hent alt i et kall, helst. dvs expand er lov, men ikke
getOne
ikke ha tilgang på hente det man ikke skal ha
implementer mine ordre
bestill igjen kan avventes inntil videre
slett kan avventes
Dermed bør vi bruke en List, samt bør det være en filter regel på pocketbase. Denne regelen skal garantere at
auth.user
ikke kan lese enorder_drink
som ikke er lagt til iuser.favorites
Siden
order_drink
ikke inneholderfavorites
eller en relasjon dit, tror jeg vi må endre litt på modellen her.Jeg tror faktisk å implementere
Mine ordre
i samme slengen kan informere hvordan datamodellen vi bør ha her skal se ut.todo for /
ExpandedDrink
ogDrink
, tenker disse er distinkt nok til å kunne dele en base, men kan være to forskjellige komponenter.Hvor vi har tre kolonner og en accordion. Det gir oss fire grupper. Men vi kan storyboarde dette sammen.