Så bygger du ett formulärbyggarverktyg

Ett formulärbyggarverktyg låter människor designa egna formulär – välja fält, sätta regler och publicera en länk – och samlar sedan in svaren. Under ytan består det av tre delar: en formulärdefinition lagrad som data, en renderare som gör om definitionen till ett fungerande formulär, och ett lager för svar med notiser och export. Innan du bygger ett, kontrollera att du verkligen behöver det: om du bara behöver ett kontaktformulär eller ett ansökningsformulär, bygg just det formuläret och hoppa över byggaren helt.

Behöver du verkligen ett byggarverktyg?

Ett byggarverktyg är ett större projekt än ett formulär, eftersom varje fälttyp måste fungera i redigeraren, i det publika formuläret, i valideringen, i lagringen, i notiserna och i exporten.

Vad ett formulärbyggarverktyg behöver

Formulärdefinitioner

Spara varje formulär som en lista med fält, lagrad som strukturerad data (JSON i en Postgres-kolumn fungerar bra). Ett fält kan se ut så här:

• id – ett stabilt ID som aldrig ändras, även om etiketten gör det
• type – text, e-post, tal, lång text, val, kryssruta, datum, fil
• label och hjälptext
• required, min / max, tillåtna filtyper
• alternativ för valfält
• ordning och eventuellt ett villkor (”visa bara om fält X är Y”)

Redigeraren ändrar listan; det publika formuläret läser den. Det är hela tricket: ingen ny kod per formulär.

Svar

• Svar – formulär, formulärversion, inskickad tid, svar kopplade till fältens ID, status (ny, läst, arkiverad).
• Filer – uppladdade filer hör hemma i fillagring, med en referens i svaret. De ska aldrig ligga inne i databasraden.

Sidor

• Formulärlista med antal svar.
• Redigerare – lägg till, flytta och konfigurera fält, med en live-förhandsvisning bredvid.
• Inställningar – bekräftelsemeddelande eller omdirigering, notis-e-post, öppnings- och stängningsdatum, gräns för antal svar.
• Publikt formulär på en egen länk, och en inbäddningsbar version för andra webbplatser.
• Svarstabell med sök, status, detaljvy och CSV-export.

Beslut och avvägningar

Versionshantering. Någon kommer att byta namn på ”Telefon” till ”Mobilnummer” efter 200 svar. Om svaren lagras per fält-ID och varje svar noterar formulärversionen visas de gamla svaren fortfarande rätt. Utan det blandas din data ihop i tysthet.

Validering körs två gånger. Kontrollera fälten i webbläsaren för snabb återkoppling, och igen på servern, eftersom vem som helst kan skicka data direkt till din endpoint. Kontrollen på servern är den som räknas.

Filuppladdningar. De medför lagringskostnader, storleksgränser, kontroll av filtyp och integritetsfrågor (CV:n, id-handlingar, medicinska formulär). Begränsa typer och storlekar och gör uppladdade filer privata som standard, läsbara enbart för formulärets ägare. Se så lägger du till filuppladdningar i din app.

Notiser. ”Mejla mig när någon skickar in” förväntas. Det kräver en e-postleverantör och en API-nyckel; se så skickar du e-post från din app.

Skräppost. Ett publikt formulär kommer att hittas av bottar. Använd ett honeypot-fält (dolt för människor, ifyllt av bottar), gränser per IP-adress, validering på servern och vid behov en captcha-tjänst.

Inbäddning. En iframe är det enklaste och säkraste sättet att lägga ett formulär på någon annans webbplats. En skriptbaserad inbäddning ser mer inbyggd ut men är svårare att bygga och säkra.

Villkorad logik. ”Visa det här fältet bara om…” är populärt men multiplicerar antalet tester. Lägg till det när grunderna sitter.

En första prompt som fungerar

Bygg ett formulärbyggarverktyg som webbapp för mitt team. Inloggade användare skapar formulär i en redigerare med live-förhandsvisning. Fälttyper: kort text, lång text, e-post, tal, datum, enkelval, kryssrutor och filuppladdning. Varje fält har ett stabilt ID, en etikett, hjälptext, en obligatorisk-flagga och typspecifika regler (min/max, alternativ, tillåtna filtyper och en storleksgräns på 10 MB). Lagra formulärdefinitionen som JSON med ett versionsnummer som ökar vid varje publicering. Varje formulär får en publik länk och en iframe-inbäddningskod. Validera svar på servern mot den publicerade versionen, lagra svaren kopplade till fältens ID och formulärversionen, och lägg uppladdade filer i privat fillagring. Lägg till ett dolt honeypot-fält och en gräns per IP-adress. Formulärägare ser en svarstabell med status (ny, läst, arkiverad), en detaljvy och CSV-export. Lagra allt i en databas. Lämna villkorad logik och e-postnotiser till senare.

Byggsteg

1. Redigerare och definition. Bygg ett formulär med alla fälttyper och titta på den sparade JSON:en tillsammans med agenten. Är den ren och stabil?
2. Publikt formulär. Fyll i det i en telefon. Kontrollera valideringsmeddelanden och bekräftelseskärmen.
3. Validering på servern. Be agenten skicka ett svar som bryter reglerna direkt till servern, förbi sidan. Det ska avvisas.
4. Versionshantering. Byt namn på och flytta fält efter några svar. Gamla svar ska fortfarande visa rätt svar.
5. Uppladdningar. Prova en fil som är för stor och en av fel typ. Bekräfta att en främling inte kan öppna en uppladdad fil genom att gissa länken.
6. Svarstabell och export. Kontrollera CSV-exporten med kommatecken, radbrytningar och accenttecken i svaren.
7. Notiser, inbäddningar, logik. Lägg till dem en i taget.

Vanliga misstag

• Att lagra svar per etikett. Etiketter ändras. Använd stabila fält-ID.
• Validering enbart i webbläsaren. Det är en bekvämlighet, inte ett skydd.
• Offentliga uppladdade filer. Formulär samlar ofta in dokument som folk inte vill ska synas.
• Inget skydd mot skräppost. Ett publikt formulär kan fyllas med skräp inom några dagar.
• Att bygga ett byggarverktyg för ett enda formulär. Bygg formuläret.
• Obegränsat antal svar i en publik produkt. Om kunder skapar formulär, sätt gränser per plan, annars kan ett populärt formulär driva upp din hostingkostnad.

När en färdig produkt är det bättre valet

Hostade formulärverktyg är utmärkta och billiga för de flesta behov. De har redan löst inbäddning, skräppost, betalningar, integrationer och tillgänglighet för dussintals fälttyper. Om ditt team bara behöver formulär, använd ett sådant – se alternativ till Typeform och alternativ till Google Forms.

Bygg själv när svaren måste leva tillsammans med din egen data (matas in i ett CRM eller en kundportal du driver), när du behöver arbetsflöden efter inskickningen som verktygen inte klarar, när var data lagras eller vem som äger den är ett krav, eller när formulär är en funktion i en produkt du säljer.

Bygga det med Mythex

I Mythex beskriver du byggarverktyget i chatten och testar redigeraren och det publika formuläret sida vid sida i live-förhandsvisningen. Mythex lägger till en dedikerad databas för formulärdefinitioner och svar, och aktiverar fillagring automatiskt när din app behöver uppladdningar (begränsad till 1 GB på Free-planen). Notis-e-post går via en leverantör du ansluter med din egen nyckel. Publicera appen på en mythex.ai-länk, eller på en egen domän i Pro, så fungerar de publika formulärlänkarna därifrån.

Frågor