Beställ en adress till en bestämd post, inte bara en länk till appens startsida. Om inloggning krävs ska samma post vara målet efteråt. Exemplen är påhittade och proven är förslag; ingen egen app har testats för artikeln.
Skilj appens adress från postens adress
Du öppnar ett ärende i appen, kopierar adressen och skickar den till en kollega. Kollegan kommer till startsidan och måste söka efter ärendet igen. Då har du delat appens adress, men inte ett fungerande mål för just den posten. Ett klick inne i appen och en adress som går att öppna direkt är två olika saker att prova.
I den här artikeln använder vi en påhittad appadress: https://min-app.example. En postadress kan vara https://min-app.example/poster/post-104. Den sista delen pekar ut testposten med id post-104. Du behöver inte välja exakt denna stavning. Det viktiga i beställningen är att två olika poster får två olika adresser och att samma post går att hitta från sin sparade adress.
Lovables publiceringsdokumentation beskriver hur en version av projektet läggs på en liveadress. Senare ändringar behöver publiceras för att nå den versionen. Gör därför proven i den publicerade app där adressfunktionen finns, med dess fullständiga adress. Ett lyckat klick i byggverktygets förhandsvisning är inte ditt facit.
En länk till en post i din app ska också hållas isär från en länk som delar själva förhandsvisningen. Nyheten om Lovables delningslänkar med lösenord och utgång handlar om den senare sortens delning. Här beställer du navigering till innehåll i den publicerade appen.
Beskriv en beständig adress med postens id
Utgå från två låtsasposter: post-104 med rubriken ”Prova lokalen” och post-205 med rubriken ”Beställ skylt”. Beställ en egen adress för varje post. Be också om en knapp ”Kopiera länk” på detaljsidan, så att du kan få postens fullständiga adress utan att behöva tolka byggverktygets adressfält.
Välj postens beständiga id som referens i beställningen. Rubriken kan då ändras från ”Prova lokalen” till ”Boka lokalen” utan att du samtidigt beställer en ny postadress. Listans radnummer är ett dåligt provmål: efter en ny sortering kan ”rad 1” betyda en annan post. Det är postens identitet du vill bevara, inte dess plats på skärmen.
React Routers dokumentation om adresser visar principen: delar av en URL kan kopplas till olika vyer, och en dynamisk del kan bära ett id. Det förklarar adressmodellen; det säger inte att din app redan har den. Du beställer beteendet och provar resultatet utan att behöva välja teknisk implementation.
Håll exempeladressen fri från namn, mejladresser och hemliga inloggningsvärden. Ett påhittat id räcker för att förklara vad du vill bygga. Ta med hela adressen när du provar, inklusive appens domän. En relativ adress som /poster/post-104 kan användas i beställningen, men är inte ensam en länk som kollegan kan öppna.
Beställ rätt post efter inloggningen
Beskriv förloppet i ordning: du öppnar adressen till post-104 när du är utloggad, får logga in och hamnar därefter på post-104 om ditt konto får läsa den. ”Inloggningen fungerar” är ett svagare krav. Ett lyckat inloggningsförsök som slutar på startsidan lämnar fortfarande ditt ursprungliga ärende olöst.
Lovables autentiseringsdokumentation skiljer standardadressen efter inloggning från de adresser som är tillåtna som omdirigeringsmål. Det är inte ett belägg för att varje app minns den post du försökte öppna. Bevarat postmål är därför ett uttryckligt acceptanskriterium i beställningen nedan.
Lägg till beständiga direktlänkar till appens poster med postens id, exempelvis /poster/post-104. Två poster ska ha olika adresser. Adressen ska fortsätta peka på samma post efter en ändrad rubrik eller sortering. Lägg en knapp ”Kopiera länk” på detaljsidan som kopierar den fullständiga adressen till den aktuella posten.
Om användaren är utloggad när en postadress öppnas ska appen begära inloggning och bevara den ursprungliga posten som mål. Efter lyckad inloggning ska användaren komma direkt till den posten om kontot får läsa den, utan att behöva öppna länken igen. Direktadressen ska fungera i en ny flik och efter omladdning i den publicerade appen.
En URL ska inte ge behörighet till innehåll. Om posten har tagits bort eller kontot saknar rätt att läsa den ska inget postinnehåll visas. Visa i båda fallen ”Posten kan inte öppnas” och en knapp ”Till mina poster”. Visa inte postens rubrik eller ägare i felmeddelandet. Lägg inga personuppgifter eller tokens i postadressen.
Beskriv först vilka delar du behöver ändra. Ändra inte andra funktioner. Använd låtsasposter och redovisa hur jag kan prova ny flik, omladdning, utloggad öppning med återgång, borttagen post och otillåten post i den publicerade appen.
Har du ännu inte fungerande konton och sparade poster, börja med Data och inloggning. Här behöver du kunna logga ut, logga in igen och känna igen samma testpost. Du behöver däremot inte bygga om hela inloggningsflödet för att beskriva vad adressen ska göra.
Prova ny flik och omladdning i den publicerade appen
Förbered post-104 som ditt testkonto får läsa, post-205 som det saknar rätt till och en tredje låtsaspost som du kan radera. Kopiera den tredje postens adress före raderingen. Använd inga verkliga privata uppgifter. Anteckna appadressen och vilken version du provar, så att nästa rättning kan jämföras med samma förutsättningar.
Gör följande fem prov. I de två första ska du redan vara inloggad med kontot som får läsa post-104. I det tredje ska du uttryckligen logga ut innan du öppnar den sparade adressen. Om appen använder en extern inloggningstjänst ska du följa samma väg som en tänkt användare skulle använda.
| Prov | Gör så här | Godkänt enligt beställningen |
|---|---|---|
| 1. Ny flik | Kopiera länken från post-104 och klistra in den i en ny flik. | Post-104 öppnas med rätt rubrik och innehåll, utan sökning i listan. |
| 2. Omladdning | Ladda om den direktöppnade postens sida. | Samma post visas igen. Du hamnar inte på startsidan eller på en annan post. |
| 3. Utloggad öppning | Logga ut, öppna den sparade länken och logga in med rätt konto. | Inloggning begärs och post-104 öppnas därefter utan att länken måste klistras in igen. |
| 4. Borttagen post | Radera den tredje låtsasposten och öppna dess sparade adress. | ”Posten kan inte öppnas” visas utan postinnehåll. ”Till mina poster” fungerar. |
| 5. Otillåten post | Öppna den förberedda adressen till post-205 med kontot som saknar läsrätt. | Samma neutrala feltext och fungerande väg tillbaka visas, utan rubrik, ägare eller postinnehåll. |
Notera för varje prov vad du gjorde, vad du förväntade dig och vad appen visade. Skriv exempelvis ”prov 3: öppnade post-104 utloggad; efter inloggning kom jag till startsidan”. Det ger modellen ett tydligt fel att rätta. Be om en avgränsad ändring och gör om det berörda provet, följt av de övriga fyra, efter nästa uppdatering.
Ge borttagna och otillåtna poster en begriplig väg tillbaka
En sparad adress kan behöva överleva längre än posten. Beställ därför felbeteendet samtidigt som direktlänken. I modellen ovan har borttagna och otillåtna poster samma neutrala text. Det är ett medvetet val: du ger användaren en väg vidare utan att felrutan behöver tala om vem som äger posten eller visa dess rubrik.
”Till mina poster” ska vara en faktisk knapp som går till kontots tillåtna lista. Prova även den. Ett begripligt meddelande på en sida som användaren inte kan lämna är bara halva beteendet. Om listan är tom behöver återvägen ändå ge en sida som går att förstå och använda.
En adress är ett navigeringsmål, inte ett tillstånd att läsa innehåll. Lovables dokumentation om åtkomst till publicerade appar skiljer åtkomst till webbplatsen från appens användarinloggning. Fortsätt i Behörigheter i Lovable för serverregler och behörighetsprov. De fem användarproven här visar det beställda navigeringsbeteendet; de ersätter inte den granskningen.
Spara beställningen tillsammans med dina fem provresultat. När du senare ändrar listan eller inloggningen har du konkreta mål att återvända till: rätt post från en sparad adress, rätt post efter inloggning och en fungerande återväg när posten inte får visas.