Discuția de selecție a cadrului JavaScript de bază WordPress continuă cu contribuții din partea liderilor comunității cu sursă deschisă

Publicat: 2017-09-27

Canalul Slack #core-js al WordPress a găzduit o întâlnire plină de viață și productivă în această dimineață condusă de Andrew Duthie. Discuția s-a concentrat mai puțin pe comparațiile specifice de cadre și mai mult pe rolul pe care un cadru îl va juca în construirea de interfețe bazate pe JavaScript pentru WordPress. Colaboratorilor li s-au alăturat dezvoltatori și lideri de bază din comunitățile React și Vue, ingineri Chrome și alte părți interesate din afara comunității WordPress.

„Acest chat se va concentra în mare măsură pe identificarea cerințelor în construirea funcțiilor de bază, suprapunerea cu autorii de pluginuri și teme și modele pentru reducerea blocării cadrului”, a spus Duthie. „În mod ideal, acesta este la un nivel mai înalt decât simpla dezbatere a meritelor unor cadre specifice în vid și ar trebui privit ca o oportunitate de a colabora între proiecte pentru a stabili o cale de urmat pentru WordPress, care va oferi flexibilitate și rezistență la schimbarea viitoare.”

Duthie a început prin a întreba ce rol ar trebui să joace un cadru în fluxul de lucru al unui dezvoltator WordPress și a cerut, de asemenea, colaboratorilor cadru-ului să-și ofere perspectivele cu privire la recomandările pentru interfețele extensibile. Această întrebare le-a oferit participanților posibilitatea de a analiza subiecte precum suportul pentru componente web, interoperabilitatea blocurilor agnostice de cadru pentru Gutenberg și modul în care acest lucru ar putea afecta ecosistemul de pluginuri WordPress.

„Nu sunt puțin de acord cu ideea că orice nucleu (în acest caz Gutenberg) îl folosește pentru a alimenta unele dintre complexitățile de construire a unei aplicații cu state va fi standardul de facto pentru dezvoltarea pluginurilor”, a spus inginerul Gutenberg Matias Ventura. „Cadru actual aici, în termeni generali, va fi ceea ce WordPress expune și API-urile.”

Cu o abordare agnostică a cadrului pentru construirea Gutenblocks, biblioteca pe care nucleul decide să o construiască nu trebuie să devină standardul de facto pentru dezvoltatorii de pluginuri, dar mulți din afara echipei Gutenberg cred că inevitabil va ajunge așa în practică. Există echipe întregi de ingineri care așteaptă această decizie, care se angajează să adopte orice cadru pe care pariază WordPress.

„Pentru a oferi o perspectivă asupra modului în care decizia WP asupra unui cadru îi afectează pe dezvoltatorii din aval, sunt dezvoltator la Universitatea din Boston, iar planul nostru este să ne concentrăm pe oricare cadru decide WP, chiar dacă Gutenberg are un API complet agnostic”, a spus Adam Pieniazek. . „Suntem în primul rând un magazin WP (aproximativ 1.000 de site-uri de instalare WP alimentează cea mai mare parte/o mare parte din prezența noastră web publică) și ajungem să creăm personalizări uriașe pe deasupra WP, care adesea necesită scufundarea în nucleu pentru a vedea ce se întâmplă de fapt în fundal . Îmi place Vue mai mult decât React personal, dar dacă WP se hotărăște asupra React, BU se va concentra pe construirea de expertiză în React pentru atunci când trebuie să aruncăm o privire/depanare dincolo de API. Nu înseamnă că nu vom folosi și Vue, dar nu va fi obiectivul nostru principal.”

Feedback-ul Pieniazek este un ecou al co-fondatorului Gravity Forms, Carl Hancock, care a spus că echipa sa este pregătită să adopte orice bibliotecă pe care WordPress o selectează.

„Oamenii vor sfârși prin a adopta orice utilizări de bază în cea mai mare parte, în ciuda curcubeelor ​​și fluturașilor pe care unii susțin că se referă la crearea unui strat de abstractizare, astfel încât dezvoltatorii de pluginuri/teme să poată folosi orice doresc”, a spus Hancock în #core- js la începutul acestei săptămâni.

Mulți participanți din afara comunității WordPress păreau să fie de acord cu o abordare agnostică a cadrului și niciunul nu a fost dornic să forțeze un singur cadru pentru toți dezvoltatorii care lucrează cu WordPress. Preocuparea rămasă este modul în care funcționează acest lucru practic și dacă îi pune pe dezvoltatori în poziția confuză de a folosi un cadru peste un cadru.

„Deoarece Gutenberg însuși va deveni o platformă pentru care să construiți, cel mai bun nivel de separare este dacă cadrul este folosit pentru a construi nucleul, dar nu este expus ca API pentru a bloca constructorii”, a spus inginerul AMP Paul Bakaus. „Acest lucru oferă cuiva posibilitatea de a înlocui fundația de bază ori de câte ori este necesar.”

Inginerul Gutenberg Riad Benguella a rezumat abordarea pe care echipa a discutat:

Cred că ceea ce încercăm să comunicăm este ceva de genul:

– WordPress Core va folosi acest cadru X intern
– Dacă vrei să-l folosești, credem că e bun
– Dacă vrei să folosești altceva, poți la fel de ușor cum ai folosi cadrul ales de Core

Benguella a mai spus că unul dintre obiectivele lui Gutenberg este „să stabilească baza pentru modul în care extindem interfața de utilizare WordPress în viitor”. Odată ce se livrează, echipa probabil își va pune ochii pe alte părți ale wp-admin și le va construi în același mod.

„Dacă toate părțile interfeței de utilizare a WP pot fi extinse printr-o interfață standard, fie că este vorba despre o simplă API „date jos, evenimente în sus” sau așteptarea unui WC, cred că acest lucru ar separa în mod clar preocupările legate de „ce cadru să folosiți pentru core. ' vs. 'ce cadru să folosești pentru dezvoltarea extensiilor'”, a spus Evan You, creatorul Vue.js.

Când i s-a cerut părerile cu privire la faptul că React va deveni un cadru principal pentru WordPress, menținătorul React, Dan Abromov, a ezitat să pledeze pentru adoptarea bibliotecii de către WordPress. Răspunsul său a subliniat necesitatea de a avea o abordare agnostică a cadrului pentru extinderea Gutenberg și viitoarele revizuiri ale interfeței WP.

„Nu cunosc bine WordPress, așa că îmi este greu să spun dacă este potrivit sau nu pentru cazul de utilizare”, a spus Abramov. „În general, folosim React pentru interfețe de utilizare extrem de interactive și constatăm că se adaptează bine cu dimensiunea aplicației. De asemenea, sunt bucuros să răspund la întrebări tehnice despre acesta. Dar cred că, în general, oamenii au păreri puternice despre, de exemplu, modelare vs expresivitate și nu cred că forțarea React asupra tuturor este cea mai bună modalitate.”

„Și eu simt la fel”, a spus Evan You. „Forțarea unui singur cadru asupra tuturor, indiferent care dintre ele, nu este o idee bună pentru IMO, deoarece este obligat să înstrăineze grupul de dezvoltatori care nu sunt în acel cadru și impune un risc mai mare de stabilitate pe termen lung.”

Abramov a spus, de asemenea, că oamenii sunt deja „foarte amar și dezbinați” cu privire la subiectul selectării unui cadru. De asemenea, el a postat pe Twitter un sentiment similar înainte de întâlnire.

„Cred că este important (și fezabil din punct de vedere tehnic) să se separe „ce cadru să folosească pentru bază” și „ce cadru folosesc dezvoltatorii comunității pentru extensii”,” a spus Evan You.

„Da, cred că există un obiectiv aici de a nu avea păreri cu privire la ceea ce expunem autorilor de pluginuri, atâta timp cât API-urile/interfețele pe care le expunem sunt suficient de flexibile (și de ușor) pentru a construi interfețele și interacțiunile pe care trebuie să le implementeze, ” a spus Andrew Duthie.

Subiectul sprijinirii interoperabilității componentelor web pentru Gutenblocks a făcut, de asemenea, parte din discuția din timpul întâlnirii.

„Deși sunt mai puțin puternice decât majoritatea cadrelor actuale în acest moment, este probabil să devină un standard W3C, asigurându-se că vor rămâne și vor evolua”, a spus Felix Arntz. „În plus, odată ce suportul pentru browser este pe deplin, există mai puține funcționalități de implementat printr-un cadru real construit pe deasupra.”

Reprezentantul Polymer.js Justin Fagnani a spus că nu este de acord că acestea sunt „mai puțin puternice” și a remarcat că componentele web sunt deja un standard W3C.

„Cred că WP este, de asemenea, o poziție unică pentru a ajuta la promovarea suportului pentru componentele web în mod nativ peste tot”, a spus dev-ul principal EventEspresso, Darren Ethier. „Aproape toate cadrele au capacitatea de a lucra cu specificațiile componentei web acum. Este doar o chestiune de implementare corectă.”

Câțiva participanți au făcut referire la custom-elements-everywhere.com, un site care afișează progresele cadrelor JS populare în comunicarea elementelor personalizate într-un mod care promovează interoperabilitatea. Matias Ventura i-a întrebat pe dezvoltatorii de bază React și Vue cum se potrivesc componentele web (și viitorul lor) în fiecare cadru în acest moment.

„În React, avem suport pentru componente web, dar nu am făcut din aceasta o prioritate mare, deoarece cazurile de utilizare au părut reduse în trecut, mai ales că adăugarea de componente web nu a avut prea mult sens într-o aplicație primară în care controlează întregul stack – dar avem totuși suport pentru ei și sunt bucuros să adăugăm mai multe, fie acum, fie în viitor”, a spus Sophie Alpert.

„La nivel înalt, cred că cadre precum React/Vue oferă ceea ce nu este cu adevărat abordat în componentele web: actualizări eficiente și declarative DOM care reacționează la schimbările de stare”, a spus Evan You. „De asemenea, acesta este motivul pentru care Polymer există deasupra WC-ului. Am recunoscut întotdeauna valoarea WC ca interfață de interoperabilitate.”

În general, participanții la întâlnire au fost respectuoși, colaborativi și dornici să-și contribuie cu expertiza pentru a ajuta contribuitorii WordPress să găsească cea mai bună cale de urmat în procesul de selecție a cadrului. Discuția va continua la întâlnirea de săptămâna viitoare și probabil în comentariile unui post Make/Core care va rezuma întâlnirea.