Întreabă-l pe barman: ce se întâmplă când se modifică marcarea blocurilor?

Sunt un dezvoltator care a început să se dezvolte cu Gutenberg recent. Există o mulțime de beneficii și caracteristici uimitoare, dar există și o mulțime de dezavantaje, inconsecvențe, precum și documentație absolut îngrozitoare și învechită.

Unul dintre cele mai rele aspecte ale lui Gutenberg din perspectiva dezvoltatorului a fost validarea blocurilor. Luați în considerare următorul scenariu. Construiesc un bloc personalizat (non-dinamic) bazat pe JavaScript, iar un editor CMS adaugă blocul la mii de pagini. Ce se întâmplă când sau dacă trebuie să actualizez marcajul blocului?

În mod implicit, toate blocurile vor intra într-o stare de invalidare și nu se vor reflecta pe front-end-ul site-ului. Editorul CMS ar trebui să intre în mii de pagini și să facă clic manual pe butonul care permite recuperarea blocului.

Au fost sugerate deprecieri de bloc ca o modalitate de a rezolva acest lucru, dar API-ul este slab documentat, confuz și pare că ar deveni de neîntreținut pe termen lung cu mai mult de câteva deprecieri.

Nu ar trebui să existe nici o modalitate prin care dezvoltatorii de blocuri să renunțe la procesul de validare, fie o modalitate globală de a recupera blocurile?

PIJAMALE

Cu siguranță nu rețineți nimic, PJ. Deși o mare parte din acest lucru este puțin mai tehnic decât îmi place de obicei să acopăr aici, la Tavernă, am decis să iau legătura cu Riad Benguella, unul dintre dezvoltatorii principali Gutenberg, pentru mai multe informații despre situație.

Înainte de a intra în răspunsul lui, am gândit un aspect al întrebării tale. Există momente când dezvoltatorii trebuie să renunțe la vechiul marcaj și să treacă la ceva nou. Cu toate acestea, acest lucru nu ar trebui să se întâmple des. În general, este un semn de arhitectură slabă dacă HTML-ul trebuie revizuit în mod regulat. Acest lucru duce și la alte probleme, cum ar fi o terță parte care nu poate menține schimbările stilistice.

Când dezvoltați blocuri sau orice tip de aplicație care scoate cod front-end, trebuie să vă gândiți la cum ar trebui să arate asta astăzi și peste 10 ani. Ce se întâmplă dacă un utilizator adaugă un CSS personalizat pentru a vă stila blocul și structura HTML a blocului s-a schimbat? Din perspectiva lor, actualizarea dvs. de blocare a stricat site-ul lor. Același lucru s-ar putea spune și pentru un alt plugin care vă extinde pluginul într-un fel.

Întrebați orice autor de temă cât de frustrant este oricând Gutenberg/WordPress își schimbă rezultatul blocului. Deși s-a îmbunătățit în ultimii doi ani, blocurile de stil pentru editor și front-end au fost adesea un coșmar de întreținere.

În calitate de dezvoltator, am încercat întotdeauna să mă gândesc la orice consecințe din lumea reală ale efectuării acestor modificări din perspectiva unui utilizator. Asta ar trebui să se întâmple din Ziua #1, nu după ce ați lansat proiectul.

Făcând acest lucru, adaugă timp la proiectul timpuriu atunci când încerci doar să-l scoți pe ușă și în mâinile utilizatorilor. Aici vă ajută să faceți un pas înapoi înainte de lansare. Îndepărtează-te de computer. Mergi la o plimbare. Gândește-te la arhitectura proiectului tău și dacă este ideal pe termen lung.

„Pentru versiunea de bloc/actualizări, este într-adevăr una dintre domeniile API-urilor Gutenberg în care trebuia să facem compromisuri arhitecturale și am decis să favorizăm experiența utilizatorului în detrimentul dezvoltatorului”, a spus Benguella.

Indiferent de metoda dvs. de dezvoltare, urmărirea abordării proiectului de experiență în primul rând pe utilizator va ajuta pe termen lung.

„Pentru a înțelege corect problema, trebuie să înțelegem cum funcționează și cum sunt editate blocurile”, a spus Benguella. „Instanțele de bloc sunt un obiect JSON, iar interfața de utilizare a editorului manipulează acel JSON, dar pentru a rămâne compatibile cu versiunea inversă, pentru a asigura păstrarea conținutului utilizatorului în cel mai lizibil format și pentru a îmbrățișa standardele web cât mai mult posibil, editorul de blocuri nu stochează obiectul JSON, ci o serializare HTML a acestuia în post_content .”

Serializarea este analizată și convertită în JSON atunci când editorul reîncarcă conținutul pentru a-l edita din nou. În etapele finale ale analizei, este la latitudinea autorului blocului să decidă cum să salveze și să analizeze obiectul.

„Acum, imaginați-vă dacă un utilizator ar modifica codul HTML salvat (serializare) și ar pune orice conținut aleatoriu acolo”, a spus Benguella. „Este posibil ca blocul să nu poată analiza corect HTML, deoarece nu se potrivește așteptărilor sale (ceea ce a fost definit de autorul blocului), ceea ce înseamnă că recrearea acelui obiect JSON pentru a fi manipulat nu va fi posibilă în acest moment .”

Când se întâmplă acest lucru, editorul de blocuri oferă utilizatorului o interfață pentru a lua o decizie în cunoștință de cauză. Ei pot încerca să „forțeze analiza” blocul JSON sau să îl convertească într-un bloc HTML sau clasic.

Același tip de invalidare se poate întâmpla atunci când un dezvoltator de plugin își actualizează blocul. Cu toate acestea, în loc de modificarea codului HTML salvat, dezvoltatorul a schimbat „așteptările” blocului - modificând modul în care acesta este salvat și analizat.

„Motiv pentru care le cerem dezvoltatorilor de blocuri să ofere deprecieri de bloc reprezentând vechiul marcaj al aceluiași bloc”, a spus Benguella. „Depreciările pot fi considerate, de asemenea, surse alternative valide pentru același bloc. Acest lucru permite editorului să analizeze vechiul marcaj atunci când este încărcat și să salveze noul marcaj înapoi dacă se face o actualizare a blocului.”

WordPress are documentație de depreciere a blocurilor. Cu toate acestea, nu este minuțios. Cea mai bună sursă de a vedea deprecierile din lumea reală este căutarea prin biblioteca de blocuri a lui Gutenberg. Blocurile depreciate au un fișier deprecated.js .

Benguella a spus că acest sistem poate fi frustrant pentru autorii de blocuri. Acest lucru este evident mai ales într-un mediu de dezvoltare atunci când se efectuează modificări. Acest lucru i-a determinat pe dezvoltatori să solicite o metodă de dezactivare a algoritmului de validare.

„Este ceva ce nu vrem să oferim în acest moment, deoarece, după cum s-a explicat mai sus, validarea este, de asemenea, importantă atunci când marcajul se modifică din alt motiv (editare externă, alt editor etc.)”, a spus el. „Deci poate cauza pierderi de conținut pentru utilizatori fără ca aceștia să știe nimic. Preferința în acest moment este dată de conștientizarea utilizatorilor.”

Echipa a îmbunătățit sistemul de validare de-a lungul timpului, permițând mici modificări care nu încalcă starea de blocare. Există, de asemenea, un bilet deschis pentru îmbunătățiri în viitor.