Block rendering pipeline: miten Gutenberg oikeasti piirtää sivun

Gutenberg näyttää käyttäjälle visuaaliselta editorilta, mutta konepellin alla kyse ei ole “tekstieditorista”, vaan rakenteellisesta renderöintijärjestelmästä. Kun sivu ladataan, WordPress ei yksinkertaisesti tulosta HTML:ää tietokannasta. Se suorittaa kokonaisen pipeline’n, jossa lohkot tulkitaan, muunnetaan ja lopulta renderöidään.

Ja tämä pipeline on paljon vähemmän maaginen – ja paljon loogisempi – kuin miltä se aluksi tuntuu.

Kaikki alkaa datasta, ei HTML:stä

Klassisessa WordPressissä sisältö oli pitkälti HTML:ää. Gutenberg muutti tämän ajattelumallin. Postauksen sisältö ei ole enää pelkkä markup, vaan lohkorakenne.

Tietokantaan tallennettu sisältö näyttää tältä:

<!-- wp:paragraph -->
<p>Tämä on kappale.</p>
<!-- /wp:paragraph -->

Tai monimutkaisemmassa muodossa:

<!-- wp:group -->
<div class="wp-block-group">
<!-- wp:heading -->
<h2>Otsikko</h2>
<!-- /wp:heading -->
</div>
<!-- /wp:group -->

Tärkeä havainto: HTML on mukana, mutta se ei ole primäärinen totuus. Primäärinen totuus on lohkorakenne.

HTML on enemmänkin snapshot.

Ensimmäinen vaihe: parsing

Kun WordPress renderöi sivun, pipeline’n ensimmäinen askel on parsing.

WordPress:

• lukee post_contentin

• tunnistaa lohkokommentit

• rakentaa lohkotietorakenteen

Funktio

parse_blocks()

Lopputulos ei ole HTML, vaan array- tai objektirakenne, joka sisältää:

• block type

• attribuutit

• inner blocks

• inner HTML

Sisältö muuttuu ohjelmalliseksi rakenteeksi.

Parsing ei renderöi mitään

Parsing ei vielä “piirrä” sivua. Se vain purkaa sisällön osiin.

Ajattele tätä AST:nä (Abstract Syntax Tree). Sama idea kuin ohjelmointikielissä:

Teksti → rakenne → suoritus

Toinen vaihe: block resolution

Kun lohkot on parsittu, WordPress joutuu ratkaisemaan:

“Mitä tämä block type tarkoittaa?”

Block type yhdistyy rekisteröityyn lohkoon:

• core block

• plugin block

• dynamic block

WordPress etsii:

• renderöintilogiiikan

• callbackit

• metadata

Block ei ole vain HTML-fragmentti. Se on komponentti, jolla on käyttäytyminen.

Staattinen vs dynaaminen renderöinti

Tässä kohtaa pipeline haarautuu.

Staattiset lohkot

Staattinen block:

• käyttää tallennettua HTML:ää

• ei vaadi serverilogiiikkaa

• renderöinti on lähes trivial

Esimerkiksi perus paragraph-block.

WordPress voi käytännössä sanoa:

“Tässä on HTML → tulostetaan.”

Dynaamiset lohkot

Dynaaminen block:

• ei luota tallennettuun HTML:ään

• käyttää render callbackia

• generoi outputin lennossa

Esimerkkejä:

• Latest Posts

• Query Loop

• Navigation

• WooCommerce-lohkot

Renderöinti ei ole enää pelkkä tulostus. Se on logiikan suoritus.

Kolmas vaihe: renderointi

Varsinainen renderöinti tapahtuu funktion

render_block()

Pipeline:

1. Block tunnistetaan

2. Callback tarkistetaan

3. HTML generoidaan

4. Inner blocks renderöidään rekursiivisesti

Tärkeä sana: rekursiivisesti.

Blockit voivat sisältää blockeja, jotka sisältävät blockeja.

Renderöinti ei ole lineaarinen prosessi. Se on puumainen traversal.

Inner blocks: pipeline’n fraktaalirakenne

Group-block ei oikeasti “sisällä HTML:ää”. Se sisältää lohkoja.

Renderöinti:

• renderöi parentin

• renderöi childrenit

• yhdistää lopputuloksen

Sama logiikka toistuu jokaisella tasolla.

Pipeline on fraktaali.

Neljäs vaihe: filtteri-ekosysteemi

Kun block renderöidään, WordPress ei vielä sano viimeistä sanaa.

Hookit astuvat näyttämölle:

• Kopioi

  render_block

• Kopioi

  pre_render_block

• block-spesifit filterit

Lisäosat voivat:

• muokata outputia

• injektoida sisältöä

• ohittaa renderöintiä

Render pipeline ei ole suljettu putki. Se on avoin järjestelmä.

Ja tästä syntyy WordPressin klassinen emergenssi.

Viides vaihe: frontend vs editor

Hauska käänne: Gutenberg renderöi kahdessa universumissa.

Editor-renderöinti

Editorissa renderöinti tapahtuu React-komponenttien kautta.

Block:

• ei ole PHP-renderöinti

• vaan JavaScript-komponentti

• käyttää block definitionia

Editor ei lue HTML:ää samalla tavalla kuin frontend.

Se lukee block dataa.

Frontend-renderöinti

Frontendissa PHP ottaa vallan.

Block:

• parsitaan

• renderöidään serverillä

• output lähetetään selaimelle

Sama sisältö, eri renderöintimoottori.

Tämä kaksoisarkkitehtuuri on Gutenbergin ydin.

Miksi tallennettu HTML on mukana?

Tämä hämmentää monia.

Jos blockit renderöidään dynaamisesti, miksi HTML tallennetaan?

Syyt ovat pragmaattisia:

• fallback-yhteensopivuus

• editorin preview

• portability

• backward compatibility

HTML toimii snapshotina.

Block metadata toimii logiikkana.

Pipeline’n ajallinen luonne

Block rendering pipeline ei ole vain tekninen prosessi. Se on ajallinen malli.

Sisältö ei ole staattinen dokumentti. Se on resepti.

Parsing → resolution → rendering → filtering

Sivu ei ole “luettu”. Se on rakennettu.

Joka latauksella.

Suorituskyky: missä kustannus syntyy?

Pipeline ei ole ilmainen.

Jokainen sivulataus:

• parsii blockit

• renderöi callbackit

• traversoi rakenteen

• suorittaa hookit

Staattinen HTML olisi halvempi.

Mutta Gutenberg ostaa joustavuutta laskennalla.

Välimuisti pipeline’n pelastajana

Tästä syystä caching on Gutenberg-maailmassa kriittinen:

• page cache

• fragment cache

• object cache

Pipeline’n kustannus voidaan amortisoida.

Pipeline’n filosofinen ydin

Gutenberg ei ole vain editori. Se on renderöintimalli.

Sisältö ei ole:

HTML → näytä

Sisältö on:

Rakenne → tulkitse → renderöi

Se on lähempänä sovelluslogiikkaa kuin dokumenttimallia.

Ja juuri siksi Gutenberg tuntuu joskus “raskaammalta”, mutta mahdollistaa asioita, joita klassinen editori ei koskaan voinut.

Block rendering pipeline ei ole mustaa magiaa.

Se on deterministinen rakennusprosessi.

WordPress ei piirrä sivua.

Se kokoaa sen.