WordPress Block Editor kokonaisuutena
WordPressin Block Editor, eli Gutenberg, ei ole vain uusi tapa kirjoittaa sisältöä. Se on kokonainen sovellusalusta WordPressin sisällä. Sen ytimessä on ajatus siitä, että editori on tilaohjattu järjestelmä, jossa kaikki mitä näet ruudulla on seurausta datasta ja sen tilasta. Tätä varten Gutenberg nojaa vahvasti Data Store -arkkitehtuuriin ja keskitettyyn state-hallintaan.
WordPressin Block Editor, eli Gutenberg, ei ole vain uusi tapa kirjoittaa sisältöä. Se on kokonainen sovellusalusta WordPressin sisällä. Sen ytimessä on ajatus siitä, että editori...
Gutenbergin Data Store on keskitetty tila-arkkitehtuuri, joka pohjautuu wp.data-kirjastoon. Ajatus on yksinkertainen mutta voimakas: sovelluksessa on yksi ensisijainen totuuden lähde, josta kaikki komponentit lukevat tilansa...
State tarkoittaa kaikkea sitä dataa, joka kuvaa editorin nykytilaa. Tämä ei ole vain sisältöä, vaan myös käyttöliittymän tila. Esimerkkejä:...
Tämä on ehkä tärkein yksittäinen store Gutenbergissä. Se sisältää kaiken lohkoihin liittyvän tilan: lohkopuun, valinnat, fokuksen, lohkojen ominaisuudet ja niiden järjestyksen....
Actions ovat tapahtumia, jotka kuvaavat mitä halutaan tapahtuvan, eivät miten se tapahtuu. Esimerkiksi “insertBlock” ei kerro, miten lohko lisätään lohkopuuhun, vaan että lohko halutaan lisätä....
Selectors eivät vain hae dataa suoraan statesta. Ne voivat myös muodostaa johdettua dataa. Esimerkiksi “getSelectedBlock” ei ole suoraan tallennettu tieto, vaan tulos usean tilakentän yhdistelmästä....
Gutenbergin React-komponentit eivät kysy dataa suoraan. Ne tilaavat tietoa storesta. Kun kyseinen data muuttuu, komponentti renderöityy uudelleen....
Oma Data Store on perusteltu silloin, kun laajennus hallitsee omaa monimutkaista tilaansa, joka ei kuulu core-storeihin. Esimerkiksi monivaiheinen editorityökalu tai laaja lisäosan hallintanäkymä hyötyy omasta...
Kaikkea ei tarvitse laittaa Data Storeen. Jos tieto ei vaikuta muihin komponentteihin tai editorin logiikkaan, paikallinen state on usein parempi. Ylisuuri store tekee järjestelmästä raskaan...
Block Editor ei ole vain editori. Se on malli sille, miten WordPressin hallintakäyttöliittymät tulevaisuudessa rakennetaan. Data Store ja keskitetty state-hallinta mahdollistavat laajennettavan, testattavan ja ennustettavan...
Kun Block Editor tuntuu monimutkaiselta, syy ei ole Reactissa tai JavaScriptissä sinänsä. Syy on siinä, että editori on tilaohjattu sovellus, ei perinteinen lomake. Data Store...
Kun Block Editor tuntuu “älykkäältä”, reagoivalta ja ennustettavalta, syy ei ole yksittäinen React-komponentti, vaan tapa jolla data kulkee järjestelmän läpi. Ymmärtämällä Data Storen ja staten toiminnan ymmärtää samalla, miksi Gutenberg toimii niin kuin se toimii – ja miksi väärin käytettynä se voi tuntua raskaalta tai vaikealta laajentaa.
Mikä Data Store on Gutenbergissä
Keskitetty totuuden lähde
Gutenbergin Data Store on keskitetty tila-arkkitehtuuri, joka pohjautuu wp.data-kirjastoon. Ajatus on yksinkertainen mutta voimakas: sovelluksessa on yksi ensisijainen totuuden lähde, josta kaikki komponentit lukevat tilansa ja johon kaikki muutokset kirjoitetaan.
Komponentit eivät säilytä editorin ydintilaa itse. Ne kysyvät sen datastorelta. Tämä poistaa ristiriitaiset tilat, vähentää synkronointiongelmia ja tekee editorin käyttäytymisestä ennustettavaa.
Redux-henkinen, mutta WordPress-mallinen
Vaikka wp.data muistuttaa monin tavoin Reduxia, se ei ole suora kopio. WordPress on tehnyt tietoisia kompromisseja, jotta järjestelmä olisi helpompi omaksua ja laajentaa. Terminologia on tuttua: actions, selectors ja reducers, mutta toteutus on WordPressin tarpeisiin räätälöity.
Tärkeää on ymmärtää, että Data Store ei ole vain kehittäjätyökalu. Se on editorin selkäranka.
State Gutenbergissä
Mitä state tarkoittaa Block Editorissa
State tarkoittaa kaikkea sitä dataa, joka kuvaa editorin nykytilaa. Tämä ei ole vain sisältöä, vaan myös käyttöliittymän tila. Esimerkkejä:
-
mitkä lohkot ovat olemassa
-
missä järjestyksessä lohkot ovat
-
mikä lohko on valittuna
-
onko sivu tallennettu
-
mitä asetuspaneeleja on auki
-
mikä postaus on kyseessä
Kun state muuttuu, editori renderöityy uudelleen. Tämä tapahtuu hallitusti Data Storen kautta.
Immutability ajattelutapana
Gutenbergin state on käytännössä immuuttia. Muutoksia ei tehdä suoraan olemassa olevaan tilaan, vaan aina luodaan uusi versio. Tämä mahdollistaa ominaisuuksia kuten undo ja redo ilman monimutkaista kirjanpitoa.
Arkkitehtonisesti tämä on kriittinen valinta. Se lisää hieman muistinkäyttöä, mutta tuo vastineeksi luotettavan ja jäljitettävän tilanhallinnan.
Core Data Storet
core/block-editor
Tämä on ehkä tärkein yksittäinen store Gutenbergissä. Se sisältää kaiken lohkoihin liittyvän tilan: lohkopuun, valinnat, fokuksen, lohkojen ominaisuudet ja niiden järjestyksen.
Kun lohko lisätään, poistetaan tai muokataan, muutos kulkee core/block-editor-storen kautta. Kaikki visuaaliset muutokset editorissa ovat seurausta tämän storen tilasta.
core/editor
core/editor vastaa postauksen tai sivun tilasta laajemmassa mielessä. Se sisältää tiedot kuten:
-
postauksen ID
-
tallennustila
-
julkaisutila
-
post meta
-
autosave-tila
Block Editor ei ole vain lohkojen muokkaaja, vaan postauksen hallintatyökalu, ja core/editor on tämän vastuualue.
core/data ja core
core/data toimii eräänlaisena yleisenä tiedonhallintakerroksena. Se huolehtii esimerkiksi REST API -kutsujen välimuistista ja synkronoinnista. core-store puolestaan tarjoaa perustason tiedot WordPress-ympäristöstä.
Nämä storet tekevät editorista reaktiivisen myös ulkoiselle datalle.
Actions: miten state muuttuu
Intentio, ei suora muutos
Actions ovat tapahtumia, jotka kuvaavat mitä halutaan tapahtuvan, eivät miten se tapahtuu. Esimerkiksi “insertBlock” ei kerro, miten lohko lisätään lohkopuuhun, vaan että lohko halutaan lisätä.
Reducerit ottavat tämän intentiotiedon ja tuottavat uuden staten. Tämä erottaa käyttöliittymän ja datalogikan toisistaan.
Deterministinen muutosketju
Yksi Data Storen suurimmista eduista on se, että jokainen muutos on deterministinen. Sama action, samassa tilassa, tuottaa aina saman lopputuloksen.
Tämä tekee editorista testattavan ja ennustettavan. Se myös mahdollistaa kehittäjälle syvemmän ymmärryksen siitä, miksi jokin tila syntyi.
Selectors: miten dataa luetaan
Johdettu tila
Selectors eivät vain hae dataa suoraan statesta. Ne voivat myös muodostaa johdettua dataa. Esimerkiksi “getSelectedBlock” ei ole suoraan tallennettu tieto, vaan tulos usean tilakentän yhdistelmästä.
Tämä vähentää tarpeetonta logiikkaa käyttöliittymäkomponenteissa ja keskittää datan käsittelyn yhteen paikkaan.
Suorituskyky ja memoisaatio
Selectors on usein memoisoitu, eli ne eivät laske arvoaan uudelleen, ellei niiden käyttämä state ole muuttunut. Tämä on kriittistä editorin suorituskyvylle, koska komponentteja on paljon ja renderöinti tapahtuu usein.
Huonosti kirjoitettu selector voi aiheuttaa turhia uudelleenrenderöintejä ja tehdä editorista tahmean.
Subscription-malli ja reaktiivisuus
Komponentit kuuntelevat statea
Gutenbergin React-komponentit eivät kysy dataa suoraan. Ne tilaavat tietoa storesta. Kun kyseinen data muuttuu, komponentti renderöityy uudelleen.
Tämä malli mahdollistaa erittäin hienojakoisen päivittymisen. Kaikki ei päivity, vain se mikä tarvitsee.
useSelect ja useDispatch
Modernissa Gutenberg-kehityksessä käytetään React hookeja, kuten useSelect ja useDispatch. Ne tekevät Data Store -integraatiosta deklaratiivista ja selkeää.
Komponentti kertoo mitä dataa se tarvitsee ja mitä toimintoja se voi kutsua. Se ei huolehdi siitä, mistä data tulee tai minne se menee.
Omien Data Storejen luominen
Milloin oma store on perusteltu
Oma Data Store on perusteltu silloin, kun laajennus hallitsee omaa monimutkaista tilaansa, joka ei kuulu core-storeihin. Esimerkiksi monivaiheinen editorityökalu tai laaja lisäosan hallintanäkymä hyötyy omasta storesta.
Pienissä tapauksissa paikallinen komponenttitila on usein parempi ratkaisu.
Integraatio core-storeihin
Omat storet voivat kommunikoida core-storejen kanssa. Tämä mahdollistaa laajennusten syvän integraation editoriin ilman, että ydintä tarvitsee muokata.
Tässä kohtaa Gutenbergin arkkitehtuuri näyttää vahvuutensa: laajennukset eivät ole irrallisia, vaan osa samaa tilamallia.
Yleisimmät virheet staten käsittelyssä
Liiallinen state
Kaikkea ei tarvitse laittaa Data Storeen. Jos tieto ei vaikuta muihin komponentteihin tai editorin logiikkaan, paikallinen state on usein parempi. Ylisuuri store tekee järjestelmästä raskaan ja vaikeasti hahmotettavan.
Sivuvaikutukset väärässä paikassa
Reducerien tulee olla puhtaita. Sivuvaikutukset, kuten API-kutsut, kuuluvat resolvereihin tai erillisiin efekteihin. Kun tämä raja hämärtyy, bugien jäljittäminen vaikeutuu merkittävästi.
Selectorien väärinkäyttö
Selector ei ole paikka tehdä raskasta laskentaa tai sivuvaikutuksia. Se on lukija, ei toimija. Kun tämä periaate rikotaan, suorituskyky kärsii.
Data Store osana WordPressin tulevaisuutta
Block Editor ei ole vain editori. Se on malli sille, miten WordPressin hallintakäyttöliittymät tulevaisuudessa rakennetaan. Data Store ja keskitetty state-hallinta mahdollistavat laajennettavan, testattavan ja ennustettavan käyttöliittymän.
Yhä useampi WordPressin osa nojaa wp.dataan, ja tämä suunta tulee vain vahvistumaan. Kehittäjälle tämä tarkoittaa, että Data Storen ymmärtäminen ei ole valinnainen taito, vaan perusosa modernia WordPress-osaamista.
Lopuksi: Gutenberg on tila, ei näkymä
Kun Block Editor tuntuu monimutkaiselta, syy ei ole Reactissa tai JavaScriptissä sinänsä. Syy on siinä, että editori on tilaohjattu sovellus, ei perinteinen lomake. Data Store ja state ovat tämän ajattelutavan ydin.
Kun tämän oivaltaa, Gutenberg lakkaa olemasta mystinen. Se muuttuu järjestelmäksi, joka tekee juuri sen mitä sen tila sanoo. Ja juuri siksi se on niin voimakas – ja niin vaativa – alusta kehittäjälle.
