Aggiornamento: Ho creato una versione più recente di questo progetto usando Vue invece di React. Dovreste leggerlo!

Index:
Parte 2 – Il Setup
Parte 3-Lo Schema

Nelle prossime settimane, attraverso una serie di articoli, spiegherò come sto usando Node.js ed Express sul backend con un server GraphQL collegato ad un database MYSQL WordPress che usa Apollo per recuperare i dati e convogliarli nei componenti React. Non preoccupatevi, userò ancora la collaudata e vera interfaccia di amministrazione di WordPress.

Se questo suona come un boccone, è perché lo è. È stato impegnativo, soprattutto perché questa è la mia prima incursione in GraphQL e Apollo. Le cose cambieranno. Il cambiamento è un bene.

Questo post spiegherà perché.

WordPress è un gigante. Il 25% di tutti i siti web sono costruiti su WordPress. È un grande CMS, con una grande comunità e un grande supporto. La gestione dei contenuti è facile e questo è l’obiettivo principale di qualsiasi CMS.

A nclud sviluppo siti WordPress quotidianamente. Amministrare siti WordPress è un piacere. Svilupparli non lo è. Lo dico come sviluppatore Javascript che ha sperimentato come sono le applicazioni Javascript isomorfe. Il Javascript mi ha fatto diventare twitterpated. Lo sviluppo di WordPress no.

Che posso dire? Non mi piace il PHP. Non mi piacciono i template. Non mi piace il “loop”. Sono stato viziato da Node, Express, Webpack, React, Babel, e ora Graph QL e Apollo.

I vantaggi di Javascript

Sono arrivato a questo solo dal lato dello sviluppo front-end. Node ed Express sono fantastici, ma la principale forza trainante dietro questa configurazione, per me, è la capacità di usare ES2015 con React e moduli CSS.

La più grande sfida dello sviluppo e del mantenimento di qualsiasi sito web o applicazione di dimensioni decenti è la capacità di gestire con grazia i cambiamenti (aggiungendo nuove caratteristiche o modificando quelle esistenti) senza rompere qualcosa. Questo di solito implica assicurarsi che l’applicazione o la modifica degli stili non abbia conseguenze indesiderate. Questo è impegnativo considerando che i CSS hanno una portata globale. Ci sono intere metodologie CSS che sono state create per alleviare questo dolore (SMACSS, BEM, ecc.), ma o coinvolgono convenzioni di denominazione esoteriche, o richiedono di ricordare uno zilione di nomi di classi diverse.

Con React, possiamo usare i moduli CSS per creare CSS a livello locale. Ogni componente ha il proprio stile, che la capacità di comporre classi CSS per altri stili, o un insieme di stili globali. È molto potente. Non è anche possibile con WordPress.

Si possono anche fare stili in linea, usare JSXStyles o una miriade di altre soluzioni – io sono un fan dei moduli CSS quindi è quello che userò.

Questo metodo significa anche che i componenti React sono facilmente sostituibili tra i progetti. Sono riutilizzabili, collegabili. Poiché gli stili sono localmente legati ad un componente, è possibile aggiungerli e rimuoverli a piacimento senza doversi preoccupare di rompere qualcos’altro.

Un altro vantaggio è la capacità di gestire lo stato dell’applicazione o del sito web in un modo molto più grazioso. Usando Apollo (di cui parlerò in un altro post) possiamo gestire non solo i dati dell’applicazione, ma lo stato dell’UI. Troppe volte in WordPress vedo un unico grande file javascript che gestisce eventi e interazioni per un intero sito web. Troppe volte vedo in quel lungo file dei test per vedere se un elemento ha una classe che dovrebbe attivare un’animazione. Questo porta a un debugging doloroso perché lo stato dell’applicazione non è coerente.

Infine, ora possiamo anche eseguire test unitari. I test sono importanti! Huzzah testing!

Isn’t WordPress Already doing Node Stuff?

Se avete seguito le notizie su WordPress, probabilmente avete sentito che Automattic, la società dietro WordPress, ha sviluppato un’interfaccia amministrativa costruita su Node. È piuttosto dolce, ed è stato open sourced. E’ alimentata dall’API REST di WordPress, quindi potete ottenere tutta la vostra roba WordPress-y in JSON e fare magie con essa.

Questo è abbastanza pulito.

Quando ho originariamente deciso di provare a sostituire PHP con Javascript, il mio primo pensiero è stato di usare questa API. Ha alcuni bei endpoint incorporati e si ha la possibilità di creare i propri. La documentazione V2 è un po’ carente, ma lo attribuisco al fatto che è così nuova.

Non sono stato molto contento del risultato, anche se ammetto di averci giocato solo per un giorno o poco più. Inoltre, dato che sto già usando React, potrei anche abbracciare l’intero ecosistema.

Entrare GraphQL

Non sarebbe fantastico se l’interfaccia utente della nostra applicazione o sito web potesse guidare i dati di cui ha bisogno? Con REST, il server invia tutti i dati di cui l’UI potrebbe aver bisogno, poi lascia che il client selezioni il resto. Potrebbe essere necessario fare chiamate a più endpoint REST per ottenere tutti i dati possibili.

Con GraphQL, il cliente determina le relazioni dei dati di cui ha bisogno e fa una query per recuperarli tutti. C’è solo un viaggio. E si ottiene esattamente ciò di cui si ha bisogno.

In ogni caso, si può leggere di più su GraphQL vs. Rest qui.

Passi successivi

Nel mio prossimo post, camminerò attraverso la configurazione base di Node.js/Express e come impostare il server GraphQL di base. Camminerò anche attraverso come sto usando Webpack per gestire i moduli CSS con SASS, come funziona la sostituzione a caldo dei moduli. Userò anche Sequelize per creare una connessione a un database MYSQL di WordPress, il che significa che non dovremo scrivere UNA SOLA LINEA DI DOMANDE SQL! Wizardry!

Nel frattempo, ho un repo Github che contiene dove sono attualmente in questo processo. Ci sono alcune query di base su Post e Postmeta e altre cose interessanti. Ovviamente è in fase di sviluppo attivo, e sono sicuro che ci sono alcuni errori imbarazzanti, quindi sentitevi liberi di prendere in giro.