Articles

WordPress cu Node, React și GraphQL (Partea 1 – Introducere)

UPDATE: De atunci am creat o versiune mai nouă a acestui proiect folosind Vue în loc de React. Ar trebui să citiți despre el!

Index:
Partea 2 – Configurarea
Partea 3-Schema

În săptămânile următoare, printr-o serie de articole, voi explica cum folosesc Node.js și Express în backend cu un server GraphQL conectat la o bază de date MYSQL WordPress care folosește Apollo pentru a prelua date și a le direcționa în componentele React. Nu vă faceți griji, voi folosi în continuare interfața de administrare WordPress încercată și adevărată.

CUT YOUR MOUTH

Dacă sună ca o îmbucătură, asta pentru că așa este. A fost o provocare, mai ales pentru că aceasta este prima mea incursiune în GraphQL și Apollo. Lucrurile se vor schimba. Schimbarea este bună.

Acest post va explica de ce.

WordPress este un gigant. 25% din toate site-urile web sunt construite pe WordPress. Este un CMS grozav, cu o comunitate grozavă și un suport grozav. Gestionarea conținutului este ușoară și acesta este principalul obiectiv al oricărui CMS.

La nclud dezvolt zilnic site-uri WordPress. Administrarea site-urilor WordPress este o plăcere. Dezvoltarea lor nu este. Spun acest lucru ca un dezvoltator Javascript care a experimentat cum arată și cum se simt aplicațiile Javascript izomorfe. Javascript m-a făcut să fiu twitterpated. Dezvoltarea WordPress nu o face.

Mi vorbind despre Javascript cu colegii de muncă.

Ce pot să spun? Nu-mi place PHP. Nu-mi plac șabloanele. Nu-mi place „bucla”. Am devenit răsfățat de Node, Express, Webpack, Webpack, React, Babel, iar acum Graph QL și Apollo.

Beneficiile Javascript

Am venit la acest lucru pur și simplu din partea de dezvoltare front-end. Node și Express sunt grozave, dar principala forță motrice din spatele acestei configurații, pentru mine, este capacitatea de a folosi ES2015 cu React și CSS-Modules.

Cea mai mare provocare a dezvoltării și întreținerii oricărui site web sau aplicație de dimensiuni decente este capacitatea de a gestiona cu grație schimbările (adăugarea de noi caracteristici sau modificarea celor existente) fără a sparge lucrurile. Acest lucru implică, de obicei, să te asiguri că aplicarea sau modificarea stilurilor nu are consecințe nedorite. Acest lucru este o provocare, având în vedere că CSS are o sferă globală. Există metodologii CSS întregi care au fost create pentru a ușura această durere (SMACSS, BEM etc.), dar acestea fie implică convenții de denumire ezoterice, fie vă cer să rețineți un miliard de nume de clase diferite.

Cu React, putem folosi module CSS pentru a crea CSS cu acoperire locală. Fiecare componentă are propriul stil propriu, care capacitatea de a compune clase CSS pentru alte stiluri, sau un set de stiluri globale. Este foarte puternic. De asemenea, nu este posibil cu WordPress.

Puteți, de asemenea, să faceți stiluri inline, să folosiți JSXStyles sau o multitudine de alte soluții – eu sunt un fan al modulelor CSS, așa că asta este ceea ce voi folosi.

Această metodă înseamnă, de asemenea, că componentele React sunt ușor de schimbat între proiecte. Ele sunt reutilizabile, pot fi conectate. Pentru că stilurile sunt local încadrate într-o componentă, puteți să le adăugați și să le eliminați după bunul plac fără să vă faceți griji că veți strica altceva.

Un alt beneficiu este capacitatea de a gestiona starea aplicației sau a site-ului web într-un mod mult mai grațios. Folosind Apollo (despre care voi vorbi într-o altă postare) putem gestiona nu doar datele aplicației, ci și starea UI. De prea multe ori în WordPress văd un singur fișier javascript mare care gestionează evenimente și interacțiuni pentru un întreg site web. De prea multe ori văd în acel fișier lung teste pentru a vedea dacă un element are o clasă care ar trebui să declanșeze o animație. Acest lucru duce la o depanare dureroasă, deoarece starea aplicației nu este consecventă.

În sfârșit, acum putem efectua și teste unitare. Testarea este importantă! Huzzah testarea!

Este clar că Tobias este încântat de testare.

Nu face WordPress deja chestii Node?

Dacă ați urmărit știrile despre WordPress, probabil că ați auzit că Automattic, compania din spatele WordPress, a dezvoltat o interfață de administrare construită pe Node. Este destul de drăguț și a fost deschis la sursă. Este alimentat de WordPress REST API, așa că puteți obține toate lucrurile WordPress-y în JSON și puteți face magie cu ele.

Este destul de frumos.

Când am stabilit inițial să încerc să înlocuiesc PHP cu Javascript, primul meu gând a fost să folosesc acest API. Are câteva puncte finale bine construite și aveți posibilitatea de a vă crea propriile puncte finale. Documentația V2 lipsește puțin, dar am pus asta pe seama faptului că este atât de nouă.

Nu am fost teribil de mulțumit de rezultat, deși recunosc că m-am jucat cu ea doar o zi sau două. De asemenea, din moment ce folosesc deja React, aș putea la fel de bine să îmbrățișez întregul ecosistem.

Intrați în GraphQL

Nu ar fi grozav dacă interfața de utilizare a aplicației noastre sau a site-ului web ar putea conduce ce date are nevoie? Cu REST, serverul trimite toate datele de care UI ar putea avea nevoie, apoi lasă clientul să sorteze restul. S-ar putea să fie nevoie să efectuați apeluri către mai multe puncte finale REST pentru a obține toate aceste date posibile.

Cu GraphQL, clientul determină relațiile de date de care are nevoie și efectuează o singură interogare pentru a le prelua pe toate. Există o singură călătorie. Și obțineți exact ceea ce aveți nevoie.

În orice caz, puteți citi mai multe despre GraphQL vs. Rest aici.

Pasii următori

În următoarea mea postare, voi trece prin configurația de bază Node.js/Express și cum să configurez serverul GraphQL de bază. De asemenea, voi trece prin modul în care folosesc Webpack pentru a gestiona modulele CSS cu SASS, cum funcționează înlocuirea modulelor la cald. De asemenea, voi folosi Sequelize pentru a crea o conexiune la o bază de date WordPress MYSQL, ceea ce înseamnă că nu va trebui să scriem NICI O SINGURĂ LINIE DE ÎNTREBĂRI SQL! Vrăjitorie!

Eu, următoarea postare.

Între timp, am un repo Github care conține unde mă aflu în prezent în acest proces. Are câteva interogări de bază Post și Postmeta și alte câteva chestii interesante. Evident, este în curs de dezvoltare activă și sunt sigur că există câteva greșeli jenante acolo, așa că nu ezitați să vă amuzați.

.