Lovable skriver appens titel, beskrivning och ikon åt dig – kontrollera utfallet innan du delar

Det här ändrades den 19 augusti

Lovables changelog beskriver publiceringen som ett enda flöde. Du väljer Publish för att se sajtens adress, dess synlighet och säkerhetsskanningen, och väljer sedan Publish igen – eller Publish changes om sajten redan är live. Changeloggen formulerar det som att projektet nu publiceras från en enda vy, där uppgifterna går att läsa i ett svep.

Samma changelogpost säger rakt ut att Lovable genererar sajtens titel, beskrivning och ikon medan appen byggs, och att det inte finns något att fylla i manuellt. Det är en bekvämlighet och en fallgrop i samma mening. Bekvämligheten är att en app aldrig går live med tom flik. Fallgropen är att ”ingenting att fylla i” lätt läses som ”ingenting att kontrollera”.

Två detaljer i dialogen är värda att notera första gången. Adressen redigeras direkt i fältet Website URL vid en första publicering, eller behålls som den är. Synligheten öppnas genom att raden under adressen väljs – den kan till exempel stå som Visible to anyone with the link. Publiceringsguiden på den här sajten går igenom vad som gäller innan du delar länken, inklusive domänvalet; den här nyheten lägger bara till metadatakontrollen i den rutinen.

De tre fälten är appens ansikte utåt

Lovables funktionsdokumentation preciserar vad de tre fälten är: sajttiteln, meta-beskrivningen och sajtikonen – favicon – som visas i webbläsarflikar och sökresultat. Det är alltså inte dekoration inne i appen, utan den text som ligger utanför appen och representerar den där du inte är med och förklarar.

Den praktiska konsekvensen: en app med fem sidor har fem uppsättningar titel och beskrivning. Om du bara delar en länk till startsidan spelar de andra mindre roll i dag, men de finns i sökresultaten den dagen sidorna hittas. Lovables egen dokumentation för sökoptimering listar dubblerade titlar mellan rutter och alltför generiska titlar och beskrivningar som vanliga fynd – vilket är precis vad automatiskt genererade fält tenderar att producera när flera sidor liknar varandra.

Läs skanningens besked utan att övertolka det

Dialogens tredje uppgift är säkerhetsskanningen. En Basic security scan körs automatiskt i bakgrunden, tar 10–15 sekunder och kontrollerar databasen efter vanliga säkerhetsproblem – bland annat misstag i row-level security-policyer och risker i schemats åtkomstkontroll. Säkerhetsdokumentationen lägger till en granskning av kända sårbarheter i npm-beroenden. Dialogen visar antingen att inga säkerhetsproblem hittades, eller hur många fynd som behöver granskas.

Det beskedet är avgränsat på ett sätt som förtjänar en mening för sig. Basic scan tittar på konfiguration och beroenden. Sårbarheter i applikationskoden – exponerade hemligheter, osäker hantering av indata, luckor i behörighetskontrollen – ligger i den valfria Deep scan, som tar omkring fyra minuter. Och Lovable skriver själva att verktygen hjälper till att hitta vanliga säkerhetsproblem men inte kan garantera fullständig säkerhet; för appar som hanterar känsliga uppgifter eller kritisk funktionalitet rekommenderar de en professionell granskning utöver detta.

Om skanningen erbjuder en fix är det värt att veta vad den kostar. Kontot innehåller tio gratisfixar som täcker både Try to fix på byggfel och de fixar som säkerhetsskanningar erbjuder, i alla arbetsytor och projekt. Varje använd fix blir tillgänglig igen 24 timmar senare, och bortom de tio körs en fix som ett vanligt chattmeddelande och drar krediter som vilken annan förfrågan som helst. Potten är genomgången i detalj i nyheten om gränsen på tio gratisfixar. För appens egna säkerhetsval finns guiden om säkerhet och personuppgifter.

Så ändrar du fälten – och vad det kostar

Det finns inget formulär för metadata. Både changeloggen och funktionsdokumentationen säger samma sak: vill du ändra hur sajten visas i webbläsarflikar, sökresultat och länkförhandsvisningar, ber du Lovable om det i chatten. Ändringen behandlas som vanlig chattanvändning och drar krediter som vilken annan byggförfrågan som helst.

En avvägning värd att göra medvetet: den genererade titeln är ofta helt användbar för en intern app som fem personer öppnar från ett bokmärke. Det är när länken ska ut till kunder, i ett nyhetsbrev eller i ett chattflöde som skillnaden mellan en beskrivande titel och en maskinskriven blir dyr att upptäcka i efterhand. Låt användningen avgöra hur mycket krediter det är värt.

Verifiera genom att titta på det omvärlden ser

Den enklaste kontrollen kostar ingenting: öppna appens liveadress i en egen flik och läs flikens text och ikon. Klistra sedan in länken i ett chattfönster eller ett utkast till mejl och se vilken förhandsvisning som byggs. Vill du kontrollera mer noggrant hänvisar Lovables dokumentation till Googles URL-inspektion, Mobile-Friendly Test och länkfelsökarna hos de sociala plattformarna.

En sak som är lätt att anta fel: Lovable kör inte om sina granskningar automatiskt när du publicerar. En granskning startas manuellt. Ett resultat du tittade på förra veckan säger alltså ingenting om den version du just har lagt ut, och ett rent besked därifrån är inget skäl att hoppa över läsningen i dialogen.

Det här är också gränsen mot en annan Lovable-ändring som rör publicering. Att appens tillitssida stängdes av som standard handlar om två särskilda adresser under /.well-known/ och ett reglage i projektinställningarna. Det är en annan yta än de tre metadatafälten, och de två kontrollerna löser inte varandra.

Lovables dokumentation säger inte om de tre fälten skrivs om vid varje bygge eller bara sätts en gång. Den här artikeln påstår därför ingendera, utan rekommenderar en läsning vid varje publicering. Kontrollera dokumentationen igen om du bygger in metadatakontrollen i en fast rutin.