Vorm ja otsing staatilisel veebisaidil: kuidas seda teha

Vastuväide, mida staatilise veebisaidi pakkumisel kõige sagedamini kuuleb: „Aga meil on vorm, otsing, uudiskiri.“ Vormi või otsingu lisamine staatilisele saidile ei nõua kogu saidi muutmist rakenduseks: iga vajadust käsitletakse eraldi, leht lehe haaval.

See juhend vaatab üle levinumad dünaamilised vajadused ja nende ühendamise viisi. See eeldab, et otsus on tehtud; kui veel mitte, alustage artiklist miks minna üle Astroga tehtud staatilisele saidile.

Kus staatilise saidi kood töötab?

Staatiline sait loob oma lehed avaldamise hetkel. See, mis peab reageerima külastaja tegevusele (sõnumi saatmine, sõna otsimine, liitumine), usaldatakse eraldi teenusele, mida kutsutakse lehelt välja.

Astro puhul on piir selgesõnaline: vaikimisi eelrenderdatakse kogu sait HTML-iks ja konkreetse lehe saab renderdada nõudmisel ühe reaga, export const prerender = false, tingimusel et majutaja jaoks on paigaldatud adapter. Ülejäänud sait ei muutu.

Nii on see näiteks veebihaagiga (webhook), aadressiga, mida väline teenus kutsub, et teatada kinnitatud maksest või saabunud sõnumist: see peab igal kutsel koodi käivitama, mida ükski ette loodud leht teha ei oska.

Kuidas lisada staatilisele saidile vorm?

Töövoog

Staatilise saidi kontaktivorm töötab kolmes etapis:

Reegel, mis hoiab ära päringute kadumise

Etappide 2 ja 3 järjekord ei ole pisiasi. Päring, mis eksisteerib ainult e-kirjas, kaob jäljetult niipea, kui saatmine ebaõnnestub, kas täitunud kvoodi või valesti seadistatud aadressi tõttu.

Sellest tuleneb reegel, mida rakendada kõikjal: kõigepealt andmebaas, siis e-kiri. Ebaõnnestunud e-kirja saab uuesti saata. Kunagi salvestamata päring on kadunud.

Valmis vormiteenused

Mitu majutajat pakuvad sisseehitatud vormihaldust: HTML-vormile lisatakse atribuut ja saadetud vormid ilmuvad liidesesse. See on mugav ettevõtte esitlussaidile, mis saab vähe päringuid. Kolm küsimust, mida enne sellele lootmist esitada:

• kus andmeid hoitakse ja kas neid saab eksportida?
• kas päringud jõuavad CRM-i või tuleb need käsitsi ümber kirjutada?
• mis juhtub, kui paketi kvoot ületatakse?

Ettevõttele, kes elab sissetulevatest päringutest, eelistame funktsiooni, mis salvestab päringu ja loob selle seejärel CRM-i. See jõuab sinna koos oma allikaga, ilma uuesti sisestamata.

Robotite vastu

Avalik vorm saab automaatseid saadetisi. Kolm lihtsat kaitsevõrku, kõik serveri poolel kontrollitud: peidetud väli, mida täidab ainult robot, minimaalne lehel viibitud aeg enne saatmist ja saadetiste piirang tunnis. Need on Challenge Us’i, meie arendatud grupiväljakutsete rakenduse ajaveebi uudiskirjaga liitumise kaitsed, millele lisandub topeltkinnitus: aadress registreeritakse alles pärast klõpsu kinnitusmeilis.

Kuidas lisada saidisisene otsing?

Avaldamisel loodud indeks

Saidisisene otsing ei vaja otsinguserverit. Avaldamise hetkel käib skript lehed läbi ja loob indeksi; brauseris pärib väike programm seda indeksit.

Pagefind, täielikult staatiline otsinguteek, jagab oma indeksi tükkideks ja otsing laadib neist vaid väikese osa. Selle autorid märgivad kokku edastatava mahu:

Challenge Us kirjutas oma indeksi ise, kahes failis: üks ajaveebi ja teine teadmusbaasi jaoks, mis luuakse avaldamisel samadest nimekirjadest kui lehed ja laaditakse esimese klahvivajutusega väljal, ajaveebi oma oli 2026. aasta septembris tihendatult umbes 130 KB. Mõlemad lähenemised töötavad staatilisel majutusel, ilma tasulise teenuseta.

Mida ette näha

• Diakriitikud ja suurtähed ei loe: „reunion“ peab leidma „Réunion“.
• Väljavõte, mis näitab, miks tulemus ilmub. Ainult pealkirjast ei piisa, kui otsitav sõna on lehe sisus.
• Iga otsingu jaoks pole eraldi aadressi. Kui iga sisestatud otsing muutub leheks, mida otsingumootorid saavad roomata, täitub sait omasisuta lehtedega. Otsing toimub lehe sees, ilma uue aadressita.

Kus hoida uudiskirja nimekirja?

Uudiskirjaga liitumine järgib vormi töövoogu. Loevad kaks valikut:

• Kus nimekiri asub. See võib asuda e-kirjade saatmise teenuses või teie andmebaasis, kust see seejärel teenusesse edastatakse. Nimekirja enda juures hoidmine võimaldab säilitada nõusoleku tõendi (märgitud lause, kuupäev, leht) ja vahetada teenust kedagi kaotamata.
• Topeltkinnitus. See kaitseb robotite tehtud või kellegi teise aadressiga tehtud liitumiste eest ja on lihtsaim tõend, et nõusolek pärineb aadressi omanikult.

Aga lehed, mis muutuvad iga külastusega?

Mõnda lehte ei saa ette luua: kliendiala, ostukorv, juhtpaneel. Astro puhul renderdatakse need nõudmisel, ükshaaval, samal ajal kui ülejäänud sait jääb staatiliseks. Kulu on käivitatud funktsioonide oma, mida tasub majutaja juures jälgida: kirjeldame, mille eest majutaja olenevalt tasu võtab.

Kui selliseid lehti saab palju ja kogu sait sõltub andmetest, mis muutuvad päeva jooksul (kinnisvarakataloog, saadavus), on teadlikult valitud serveripoolne renderdamine hästi seadistatud vahemäluga lihtsam kui kokkuklopsitud staatiline sait.

Kust alustada

Koostage nimekiri kõigest, mis peab teie praegusel saidil reageerima: vormid, otsing, liitumised, kliendiala. Iga rida leiab koha mõnes ülaltoodud töövoos ja just see nimekiri ütleb, mida majutus peab käivitama ja arvestama.

Kui teie sait töötab praegu WordPressi, Drupali või Joomla peal, lähtub meie üleminek staatilisele saidile teie lehtede inventuurist ja võrdleb enne avaldamist iga lehte vana saidiga.

Korduma kippuvad küsimused

Allikad

1. Vaikimisi eelrenderdatakse kogu sait (uus vahekaart)docs.astro.build