Op 5 augustus bracht Sanity hun Visual Editing-gids voor Astro uit - en eerlijk gezegd: het is een geweldige feature. Als je met Sanity en Astro werkt, ga het lezen. Een paar weken voor ze het uitbrachten, had ik de kans om iemand van hun team een vergelijkbare setup te laten zien die ik aan het bouwen was. Het gesprek was erg leuk. Daarna ging ik op vakantie, zij brachten het uit, en hier zijn we.
Dit schrijf ik niet om een claim te leggen. Ik schrijf het omdat wat zij uitbrachten en wat ik bouwde niet helemaal hetzelfde zijn - en de verschillen interessant genoeg zijn om te documenteren.
Wat Sanity heeft uitgebracht
Sanity's Visual Editing voor Astro is een verbeterde versie van hun Presentation Tool. Je opent Studio, je frontend laadt als preview-iframe daarin, en je klikt op een element in die preview om het overeenkomende veld in het Studio-paneel rechts te activeren. Je bewerkt daar. Wanneer je opslaat, herlaadt de preview om bijgewerkte content op te halen.
Dat is echt nuttig - vooral voor contentteams die al in Studio leven. Maar het is geen inline bewerking, en je klant moet nog steeds inloggen op een apart back-end-tool.
Wat wij bouwden
Die blauwe rand rondom de kop is een contenteditable-veld op de live pagina. Je klikt erop en typt direct. De wijziging wordt naar Sanity gepusht en direct zichtbaar in de pagina - geen Studio-paneel, geen contextwisseling, geen herladen.contenteditable-veld op de live pagina. Je klikt erop en typt direct. De wijziging wordt naar Sanity gepusht en direct zichtbaar in de pagina - geen Studio-paneel, geen contextwisseling, geen herladen.
Elk tekstelement op de pagina werkt zo. Een kop aanpassen, een typfout corrigeren, een alinea herschrijven - allemaal direct op de pagina, allemaal opgeslagen in Sanity op de achtergrond.
Knoppen
Elke knop heeft een zwevend paneel met twee tabbladen. Stijl bepaalt het tekstlabel, de knopvariant (Primary, Ghost of Secondary) en de vorm (Pill of Afgerond). Link bepaalt waar hij naartoe wijst - externe URL, anker of interne pagina.
Je kunt individuele knoppen verwijderen, herordenen of een nieuwe toevoegen met de + aan het einde van de rij. Studio niet nodig.
Content toevoegen
Met de blok-kiezer voeg je nieuwe contentblokken toe zonder Studio te openen. Eyebrow-label, kop, alinea, knoppengroep, video, kaartgrid, processtappen, FAQ - elk bloktype koppelt aan een Sanity-documentarray en wordt op de juiste positie ingevoegd.
Je kunt zelfs nieuwe blogberichten direct vanaf de frontend aanmaken. Titel, URL, categorie, datum, beschrijving en tekst - allemaal in een modal op de live site.
Het deel dat Sanity aan jou overlaat: sessies
Sanity's Astro-gids gebruikt een enkel ondertekend geheim om het preview-iframe te activeren. Het werkt, maar het is het begin van het probleem, niet het einde.
Wij bouwden een twee-cookie sessiemodel:
Bewerk-cookie - voor direct bewerken op de live site. Redis-backed sessies, inlogsnelheidslimiet, SHA-256 wachtwoordvergelijking en fail-closed gedrag in productie. Als Redis uitvalt, stopt het bewerken - de juiste afweging.
Preview-cookie - voor het Sanity Presentation-iframe. In productie draait Studio op een ander origin, wat betekent dat elke cookie in het iframe als third-party wordt beschouwd en geblokkeerd. We gebruiken het CHIPS / Partitioned cookie-attribuut zodat de preview-cookie wordt ingesteld en gelezen binnen het iframe, afgebakend tot de juiste partitie, en third-party cookie-blokkering in Safari en Chrome overleeft.
Sanity's documentatie noemt Partitioned als voetnoot voor Safari-ondersteuning. Voor ons betekende het uitzoeken ervan meerdere uren debuggen van een leeg preview-venster in productie, terwijl alles prima werkte in dev.
Hint-cookie - een niet-HttpOnly-metgezel van de bewerk-cookie waarmee voorgerenderde pagina's de bewerkingsmodus client-side kunnen detecteren zonder het sessietoken bloot te leggen. De bewerk-cookie is HttpOnly en onzichtbaar voor JavaScript.
Plus: een documenttype-allowlist in de patch-API zodat alleen specifieke Sanity-typen kunnen worden geschreven, en een open redirect-beveiliging op de preview-enable-route.
Het echte verschil
Bij Sanity's Visual Editing leeft de frontend als preview-iframe in Studio. Je klikt op een element in de preview, het overeenkomende veld activeert in het paneel rechts, en je bewerkt daar. Slim - maar je werkt nog steeds in een back-end-tool. Je klant moet weten wat Sanity is, zijn weg vinden in de Studio-interface, en heen en weer schakelen tussen de preview en het bewerkpaneel.
Wat wij bouwden draait dat volledig om. De klant logt in op zijn eigen website - geen back-end, geen apart tool, gewoon zijn site met een login. Ze klikken op de tekst die ze willen wijzigen en typen direct erop. Sanity verwerkt alles op de achtergrond, onzichtbaar.
▎ Sanity's Visual Editing vereist server-side rendering en
▎ triggert een volledige herlading van de pagina bij elke
▎ opslag. Ons systeem patcht de DOM direct - geen herladen,
▎ geen server round-trip. De wijziging is live voordat
▎ Sanity de schrijfactie heeft bevestigd.
Als Interaction Designer is dat onderscheid het hele punt. De beste interface voor het bewerken van een website is de website zelf. Klanten hoeven geen CMS te leren om een kop te wijzigen. Het moment dat je iemand naar een apart paneel stuurt, voeg je wrijving toe - en wrijving is precies waar klanten stoppen met updaten en beginnen met mailen naar hun ontwikkelaar.
Wat volgt
Deze bewerkingslag is onderdeel van een eigen interne project- een opleverings-systeem voor klanten, gebouwd op Astro en Sanity. Elke site die ik oplever in Astro, bevat deze laag standaard.
Sanity's Visual Editing-release is een goed teken voor iedereen die in deze richting bouwt. De feature is echt geweldig - en er is nog veel ruimte om verder op te bouwen.