Chiedi al barista: cosa succede quando il markup del blocco cambia?

Sono uno sviluppatore che ha iniziato a sviluppare recentemente con Gutenberg. Ci sono un sacco di incredibili vantaggi e funzionalità, ma ci sono anche un sacco di inconvenienti, incongruenze e documentazione assolutamente orribile e obsoleta.

Uno degli aspetti peggiori di Gutenberg dal punto di vista degli sviluppatori è stata la convalida dei blocchi. Considera il seguente scenario. Costruisco un blocco basato su JavaScript personalizzato (non dinamico) e un editor CMS aggiunge il blocco a migliaia di pagine. Cosa succede quando o se devo aggiornare il markup del blocco?

Per impostazione predefinita, tutti i blocchi entreranno in uno stato di invalidamento e non si rifletteranno sul front-end del sito. L'editor CMS dovrebbe entrare in migliaia di pagine e fare clic manualmente sul pulsante che consente di recuperare il blocco.

Le deprecazioni dei blocchi sono state suggerite come un modo per risolvere questo problema, ma l'API è scarsamente documentata, confusa e sembra che diventerebbe ingestibile a lungo termine con più di alcune deprecazioni.

Non dovrebbe esserci un modo per gli sviluppatori di blocchi di annullare il processo di convalida o un modo globale per recuperare i blocchi?

PJ

Di certo non stai trattenendo nulla, PJ. Sebbene gran parte di questo sia un po' più tecnico di quello che in genere mi piace trattare qui alla Taverna, ho deciso di contattare Riad Benguella, uno degli sviluppatori principali di Gutenberg, per avere maggiori informazioni sulla situazione.

Prima di approfondire la sua risposta, ho riflettuto su un aspetto della tua domanda. Ci sono momenti in cui gli sviluppatori devono deprecare il vecchio markup e passare a qualcosa di nuovo. Tuttavia, questo non dovrebbe accadere spesso. In generale, è un segno di scarsa architettura se l'HTML deve essere revisionato regolarmente. Questo porta anche ad altri problemi, come ad esempio una terza parte che non è in grado di mantenere i cambiamenti stilistici.

Quando si sviluppano blocchi o qualsiasi tipo di applicazione che genera codice front-end, è necessario pensare a come dovrebbe essere oggi e tra 10 anni. Cosa succede se un utente aggiunge alcuni CSS personalizzati per definire lo stile del blocco e la struttura HTML del blocco è cambiata? Dal loro punto di vista, il tuo aggiornamento del blocco ha danneggiato il loro sito. Lo stesso si potrebbe dire per un altro plugin che estende il tuo plugin in qualche modo.

Chiedi a qualsiasi autore di temi quanto sia frustrante ogni volta che Gutenberg/WordPress cambia il suo output di blocco. Sebbene sia migliorato negli ultimi due anni, i blocchi di stile per l'editor e il front-end sono stati spesso un incubo di manutenzione.

Come sviluppatore, ho sempre cercato di pensare a tutte le conseguenze nel mondo reale di apportare queste modifiche dal punto di vista di un utente. Ciò dovrebbe accadere dal Day #1, non dopo che hai rilasciato il tuo progetto.

In questo modo si aggiunge tempo al progetto iniziale quando si sta solo cercando di farlo uscire dalla porta e nelle mani degli utenti. È qui che aiuta fare un passo indietro prima del rilascio. Allontanati dal computer. Vai a fare una passeggiata. Pensa all'architettura del tuo progetto e se è l'ideale a lungo termine.

"Per quanto riguarda il blocco delle versioni/gli aggiornamenti, è davvero una delle aree delle API Gutenberg in cui dovevamo fare compromessi architetturali e abbiamo deciso di favorire l'esperienza dell'utente rispetto a quella dello sviluppatore", ha affermato Benguella.

Indipendentemente dal tuo metodo di sviluppo, seguire l'approccio del progetto di una user-first experience ti aiuterà a lungo termine.

"Per comprendere correttamente il problema, è necessario capire come funzionano e come vengono modificati i blocchi", ha affermato Benguella. "Le istanze di blocco sono un oggetto JSON e l'interfaccia utente dell'editor manipola quel JSON, ma per mantenere la compatibilità con le versioni precedenti, per garantire la conservazione del contenuto dell'utente nel formato più leggibile e per abbracciare il più possibile gli standard web, l'editor di blocchi non memorizza l'oggetto JSON ma una sua serializzazione HTML in post_content .”

Tale serializzazione viene analizzata e convertita in JSON quando l'editor ricarica il contenuto per modificarlo nuovamente. Nelle fasi finali dell'analisi, spetta all'autore del blocco decidere come salvare e analizzare l'oggetto.

"Ora, immagina se un utente ha modificato l'HTML salvato (serializzazione) e ci ha semplicemente inserito qualsiasi contenuto casuale", ha affermato Benguella. "Il blocco potrebbe non essere in grado di analizzare correttamente l'HTML perché non corrisponde alle sue aspettative (ciò che è stato definito dall'autore del blocco), il che significa che ricreare quell'oggetto JSON per essere manipolato non sarà possibile a questo punto .”

Quando ciò accade, l'editor di blocchi fornisce all'utente un'interfaccia per prendere una decisione informata. Possono tentare di "forzare l'analisi" del blocco JSON o convertirlo in un blocco HTML o classico.

Questo stesso tipo di invalidamento può verificarsi quando uno sviluppatore di plugin aggiorna il proprio blocco. Tuttavia, invece della modifica dell'HTML salvato, lo sviluppatore ha modificato le "aspettative" del blocco, alterando il modo in cui viene salvato e analizzato.

"Ecco perché chiediamo agli sviluppatori di blocchi di fornire deprecazioni di blocchi che rappresentano il vecchio markup dello stesso blocco", ha affermato Benguella. “Le deprecazioni possono anche essere considerate fonti alternative valide per lo stesso blocco. Ciò consente all'editor di analizzare il vecchio markup quando viene caricato e di salvare il nuovo markup se viene effettuato un aggiornamento al blocco".

WordPress ha una documentazione sulla deprecazione dei blocchi. Tuttavia, non è completo. La migliore fonte per vedere le deprecazioni del mondo reale è guardare attraverso la libreria di blocchi di Gutenberg. I blocchi obsoleti hanno un file deprecated.js .

Benguella ha affermato che questo sistema può essere frustrante per gli autori di blocchi. Ciò è particolarmente evidente in un ambiente di sviluppo quando si apportano modifiche. Ciò ha portato gli sviluppatori a chiedere un metodo per disabilitare l'algoritmo di convalida.

"È qualcosa che non vogliamo fornire al momento perché, come spiegato sopra, la convalida è importante anche quando il markup cambia per un altro motivo (modifica esterna, un altro editor, ecc.)", ha affermato. “Quindi potrebbe causare la perdita di contenuti per gli utenti senza che loro ne siano a conoscenza. La preferenza in questo momento è data alla consapevolezza degli utenti".

Il team ha migliorato nel tempo il sistema di convalida, consentendo piccole modifiche che non interrompono lo stato di blocco. C'è anche un biglietto aperto per miglioramenti futuri.