Ce este Redux: un ghid al designerului

Ai auzit de Redux? Ce este? Fără google, te rog!

• „Chestii de backend de lux.”
• „Am auzit de el, dar nu știu ce este. Este probabil un cadru React?”
• „O modalitate mai bună de a stoca și gestiona stările într-o aplicație React.”

Am pus această întrebare peste 40 de designeri. Cele de mai sus sunt răspunsurile lor tipice. Mulți dintre ei știu că Redux funcționează cu React și că sarcina sa este „gestionarea statului”.

Dar știi ce înseamnă cu adevărat acest „management de stat”? Știți că puterea reală a lui Redux este dincolo de gestionarea statului? Știți că Redux nu necesită neapărat React pentru a funcționa ? Doriți să vă alăturați discuției echipei dvs. (sau cel puțin discuțiilor de prânz) despre utilizarea Redux? Doriți să proiectați având în vedere cum funcționează Redux?

Cu ajutorul acestui articol, aș dori să vă arăt o imagine completă a Redux : ce poate face, de ce își face lucrurile, care sunt dezavantajele, când să îl utilizați și cum se leagă de design.

Scopul meu este să ajut designeri ca tine. Chiar dacă nu ați scris o singură linie de cod înainte, cred că este totuși posibil și benefic (și distractiv) să înțelegeți Redux. Așteptați-vă la engleză simplă și doodle-uri - fără coduri sau discuții abstracte.

Gata de plimbare?

Ce este Redux?

La un nivel super-înalt, Redux este un instrument pe care dezvoltatorii îl folosesc pentru a le ușura viața. După cum mulți dintre voi ați auzit, sarcina sa este „gestionarea statului”. Voi explica ce înseamnă managementul de stat câteva secțiuni mai târziu. În acest moment, vă las cu această poză:

De ce ar trebui să-ți pese?

Redux este mai mult despre funcționarea interioară a unei aplicații decât despre aspectul ei. Este un instrument oarecum complex, cu o curbă de învățare abruptă. Înseamnă asta că noi, ca designeri, ar trebui să stăm departe de asta?

Nu. Cred că ar trebui să-l îmbrățișăm. Un designer de mașini ar trebui să înțeleagă pentru ce este motorul, nu? Pentru a proiecta cu succes interfețele aplicațiilor, designerii ar trebui să aibă, de asemenea, cunoștințe solide despre lucrurile sub capotă . Ar trebui să aflăm ce poate face, să înțelegem de ce îl folosesc dezvoltatorii și să fim conștienți de avantajele și implicațiile sale.

„Designul nu este doar ceea ce arată și se simte. Designul este modul în care funcționează.”

- Steve Jobs

Ce poate face Redux?

Mulți oameni folosesc Redux pentru a gestiona starea în aplicațiile React. Este cel mai frecvent caz de utilizare în sălbăticie, iar Redux îmbunătățește aspectele în care React nu se descurcă bine (încă).

Cu toate acestea, veți vedea în curând că puterea reală a Redux depășește asta. Să începem prin a afla ce înseamnă cu adevărat managementul de stat.

Managementul Statului

Dacă nu sunteți sigur ce înseamnă această „stare”, să-l înlocuim cu un termen mai generic: „date”. Starea reprezintă date care se modifică din când în când . Starea determină ce este afișat pe interfața cu utilizatorul.

Ce înseamnă management de stat? În general, există trei aspecte ale datelor pe care ar trebui să le gestionăm într-o aplicație:

1. Preluarea și stocarea datelor
2. Atribuirea datelor elementelor UI
3. Schimbarea datelor

Să presupunem că construim o pagină Dribbble shot. Care sunt datele pe care vrem să le afișăm pe pagină? Acestea includ fotografia de profil a autorului, numele, GIF-ul animat, numărul de inimi, comentariile și așa mai departe.

În primul rând, trebuie să preluăm toate aceste date de la un server din cloud și să le punem undeva. Apoi, trebuie să afișăm efectiv datele. Trebuie să atribuim părți din aceste date elementelor UI corespunzătoare care reprezintă ceea ce vedem de fapt în browser. De exemplu, atribuim adresa URL a fotografiei de profil atributului src al unei etichete HTML img :

 <img src='https://url/to/profile_photo'>

În cele din urmă, trebuie să ne ocupăm de modificările datelor. De exemplu, dacă un utilizator adaugă un comentariu nou la o fotografie Dribbble sau adaugă o stea, trebuie să actualizăm codul HTML în consecință.

Coordonarea acestor trei aspecte ale statului este o parte importantă în dezvoltarea front-end, iar React are diferite grade de sprijin pentru această sarcină. Uneori, facilitatea încorporată în React funcționează suficient de bine. Dar pe măsură ce aplicația devine mai complexă, starea sa poate deveni mai greu de gestionat doar cu React. De aceea, mulți oameni încep să folosească Redux ca alternativă.

Preluarea și stocarea datelor

În React, împărțim o interfață de utilizare în componente. Fiecare dintre aceste componente poate fi împărțită în componente mai mici (consultați „Ce este React?”).

Dacă interfața noastră de utilizare este structurată în acest fel, când preluăm datele și unde să le stocăm înainte de a popula interfața de utilizare?

Imaginați-vă că în fiecare componentă locuiește un bucătar . Preluarea datelor de pe servere este ca și cum ați procura toate ingredientele necesare pentru a pregăti felurile de mâncare.

O modalitate naivă este de a prelua și stoca datele unde și când este nevoie. Este ca și cum fiecare bucătar iese să cumpere legume și carne direct de la fermele îndepărtate.

Această abordare este risipitoare. Ar trebui să apelăm serverul de mai multe ori din mai multe componente - chiar și pentru aceleași date. Bucătarii ar pierde mult benzină și timp călătorind înainte și înapoi.

Cu Redux, preluăm datele o dată și le stocăm într-un loc central, numit convenabil „magazin”. Datele sunt apoi gata de utilizare oricând de către orice componentă. Acest lucru nu este diferit de faptul că aveți un supermagazin în apropiere, unde bucătarii noștri pot cumpăra toate ingredientele. Supermagazinul trimite camioane pentru a transporta înapoi legume și carne în vrac de la ferme. Este mult mai eficient decât să le ceri bucătarilor individuali să meargă ei înșiși la ferme!

Magazinul servește și ca sursă unică a adevărului. Componentele preiau întotdeauna date din magazin, nu din altă parte. Acest lucru menține tot conținutul UI consistent.

Atribuirea datelor la elementele UI

Cu doar React, există de fapt o modalitate mai bună de a prelua și stoca date. Îl putem cere pe foarte amabilul nostru bucătar Shotwell să facă cumpărături pentru toți prietenii săi bucătari. El conducea un camion la ferme și ducea înapoi bunătățile. Am putea prelua date dintr-o componentă container, de exemplu, componenta „Shot” din exemplul Dribbble și să le folosim ca sursă unică de adevăr.

Această abordare este mai eficientă decât modul naiv de a prelua date din fiecare componentă. Dar cum transmite Shotwell ingredientele altor bucătari? Cum se transmit datele către componentele care redau de fapt elemente HTML? Trecem date de la componentele exterioare la componentele interioare, cum ar fi bastonul într-un releu, până când datele ajung la destinație.

De exemplu, adresa URL a avatarului autorului trebuie să fie transmisă de la „Shot”, la „ShotDetail”, la „Title” și, în final, la eticheta <img> . Dacă bucătarii noștri locuiesc într-un apartament, chiar arată așa:

Pentru a livra date la destinație, ar trebui să angajăm toate componentele de pe cale, chiar dacă nu au nevoie de date deloc. Ar fi foarte enervant dacă ar fi multe etaje!

Ce se întâmplă dacă supermagazinul face livrare din ușă în ușă? Cu Redux ¹ , putem conecta orice date în orice componentă, fără a afecta deloc alte componente, astfel:

¹ Pentru a fi absolut exact, este o altă bibliotecă numită react-redux care predă datele componentelor React, nu Redux în sine. Dar din moment ce react-redux face doar instalațiile sanitare și oamenii folosesc aproape întotdeauna Redux și react-redux împreună, cred că este bine să includeți acest lucru ca unul dintre beneficiile Redux.

Notă : În cea mai recentă versiune de React (16.3), există un nou API „context” care face aproape aceeași treabă în ceea ce privește conectarea datelor în componente. Deci, dacă acesta este singurul motiv pentru care echipa dvs. folosește Redux, luați în considerare serios să faceți upgrade la React 16.3! Consultați documentul oficial pentru mai multe informații (atenție: o mulțime de cod înainte).

Schimbarea datelor

Uneori, logica actualizării datelor într-o aplicație poate fi destul de complexă. Ar putea implica mai mulți pași care depind unul de celălalt. Este posibil să fie nevoie să așteptăm răspunsurile de la mai multe servere înainte de a actualiza starea aplicației. Este posibil să fie nevoie să actualizăm multe locuri din stat în momente diferite în condiții diferite.

Poate fi copleșitor dacă nu avem o structură bună pentru toată această logică. Codul ar fi greu de înțeles și de întreținut.

Redux ne permite să divizăm și să cucerim . Oferă o modalitate standard de a împărți logica actualizării datelor în mici „reductoare”. Aceste reductoare lucrează armonios împreună pentru a finaliza o acțiune complexă.

Fii cu ochii pe dezvoltarea recentă a lui React, totuși. Ca și în cazul API-ului „context”, ar putea exista un nou API „setState” într-o versiune viitoare a React. Ar facilita împărțirea logicii complexe de actualizare în părți mai mici. Odată ce acest nou API devine disponibil, este posibil să nu mai aveți nevoie de Redux pentru a gestiona acest aspect al managementului de stat.

Adevărata putere a Redux

Până acum, se pare că Redux este doar un leucoaniu pentru React. Oamenii folosesc Redux pentru a îmbunătăți aspectele pe care React nu le face bine (încă). Dar React ajunge repede din urmă! De fapt, Dan Abramov, creatorul Redux, s-a alăturat echipei de bază React de la Facebook acum câțiva ani. Au fost ocupați să lucreze la îmbunătățirile menționate mai sus pentru React: context API (lansat în 16.3), mai bun API pentru preluarea datelor (demovat în februarie 2018), un setState API mai bun și așa mai departe.

Va face Redux să fie depășit?

Ghici ce? Nu ți-am arătat încă puterea reală a Redux!

Redux îi obligă pe dezvoltatori să urmeze câteva reguli stricte, care aduc lui Redux multă putere (da, puterea disciplinei!):

1. Toate datele (starea aplicației) trebuie descrise în text clar. Ar trebui să puteți nota toate datele cu un stilou pe hârtie.
2. Fiecare acțiune (modificarea datelor) trebuie să fie descrisă în text clar. Trebuie să scrieți ce veți face înainte de a schimba ceva. Nu puteți modifica datele fără a lăsa un semn. Acest proces se numește „trimiterea unei acțiuni” în argou Redux.
3. Codul dvs. care modifică datele trebuie să se comporte ca o formulă matematică. Trebuie să returneze același rezultat având în vedere aceeași intrare. Pătratul lui 4 este întotdeauna 16, indiferent de câte ori îl rulați.

Când urmați aceste reguli pentru a crea aplicații, se întâmplă magia. Permite o mulțime de funcții interesante care altfel sunt dificil sau costisitoare de implementat. Aici sunt cateva exemple. ²

² Am colectat aceste exemple din postarea lui Dan Abramov „S-ar putea să nu ai nevoie de Redux” și „React Beginner Question Thread”.

Anulați, refaceți

Funcția populară de anulare/refacere necesită planificare la nivel de sistem. Deoarece anularea/refacerea trebuie să înregistreze și să reia fiecare modificare a datelor din aplicație, trebuie să o luați în considerare în arhitectură încă de la început. Dacă se face ca o idee ulterioară, ar necesita schimbarea multor fișiere, ceea ce este o rețetă pentru nenumărate erori.

Deoarece Redux necesită ca fiecare acțiune să fie descrisă în text clar, suportul pentru anulare/refacere este aproape gratuit. Instrucțiunile despre cum să implementați anularea/refacerea cu Redux se potrivesc într-o pagină simplă.

Mediu de colaborare

Dacă construiți o aplicație similară cu Google Docs în care mai mulți utilizatori lucrează împreună la o sarcină complexă, luați în considerare utilizarea Redux. Probabil că va face o mulțime de haltere pentru tine.

Redux face foarte ușor să trimiteți ceea ce se întâmplă prin rețea. Este simplu să primiți acțiunile pe care le efectuează un alt utilizator pe o altă mașină, să redați modificările și să vă îmbinați cu ceea ce se întâmplă la nivel local.

Interfață de utilizare optimistă

Interfața de utilizare optimistă este o modalitate de a îmbunătăți experiența utilizatorului unei aplicații. Face ca aplicația să pară să răspundă mai rapid într-o rețea lentă. Este o strategie populară în aplicațiile care necesită răspunsuri în timp real, de exemplu, un joc cu împușcături la persoana întâi.

Ca exemplu simplu, în aplicația Twitter, atunci când faceți clic pe inima unui tweet, acesta trebuie să solicite serverului să facă câteva verificări, de exemplu, dacă acel tweet mai există. În loc să aștepte multe secunde pentru rezultat, aplicația alege să trișeze! Presupune că totul este în regulă și arată imediat o inimă plină.

Această abordare funcționează pentru că de cele mai multe ori totul este în regulă. Când lucrurile nu sunt în regulă, aplicația va anula actualizările anterioare ale UI și va aplica rezultatul real de pe server, de exemplu, va afișa un mesaj de eroare.

Redux acceptă interfața de utilizare optimistă în același mod ca și pentru anularea și refacerea. Facilitează înregistrarea, reluarea și anularea modificărilor datelor atunci când se primește un rezultat negativ de la server.

Persistență și pornire de la stat

Redux facilitează salvarea a ceea ce se întâmplă într-o aplicație în stocare. Mai târziu, chiar dacă computerul repornește, aplicația poate încărca toate datele și poate continua exact din același loc, ca și cum nu ar fi fost niciodată întreruptă.

Dacă construiți un joc cu Redux, veți avea nevoie doar de încă câteva linii de cod pentru a salva/încărca progresul jocului, fără a modifica restul codului.

Sisteme cu adevărat extensibile

Cu Redux, trebuie să „trimiteți” o acțiune pentru a actualiza orice date dintr-o aplicație. Această restricție face posibilă conectarea la aproape fiecare aspect al ceea ce se întâmplă într-o aplicație.

Puteți crea aplicații cu adevărat extensibile în care fiecare funcție poate fi personalizată de utilizator. De exemplu, consultați Hyper, o aplicație de terminal construită cu Redux. Extensia „hiperputere” adaugă stropi la cursor și scutură fereastra. Cum îți place acest mod „wow”? (Poate nu foarte util, dar suficient pentru a impresiona utilizatorii)

Depanare în călătorie în timp

Ce zici de a putea călători în timp atunci când depanezi o aplicație? Rulați aplicația, derulați înapoi sau înainte de câteva ori pentru a găsi locul exact când apare eroarea, remediați eroarea și redați din nou pentru a confirma.

Redux face ca acest vis al dezvoltatorilor să devină realitate. Redux DevTools vă permite să manipulați progresul unei aplicații care rulează ca un videoclip YouTube - trăgând un glisor!

Cum functioneazã? Vă amintiți cele trei reguli stricte pe care Redux le aplică? Acesta este sosul secret al magiei.

Rapoarte automate de erori

Imaginează-ți asta: un utilizator găsește ceva în neregulă în aplicația ta și dorește să raporteze eroarea. Ea își amintește cu grijă și descrie ceea ce a făcut. Apoi, un dezvoltator încearcă să urmeze pașii manual pentru a vedea dacă eroarea apare din nou. Raportul de eroare poate fi vag sau inexact. Dezvoltatorului îi este greu să găsească unde este eroarea.

Acum, ce zici de asta. Utilizatorul face clic pe butonul „Raportează erori”. Sistemul trimite automat ceea ce a făcut ea către dezvoltator. Dezvoltatorul face clic pe butonul „Replay bug” și urmărește cum se întâmplă exact acel eroare. Gângăria este strivită pe loc, toată lumea este fericită!

Este exact ceea ce s-ar întâmpla dacă utilizați Redux Bug Reporter. Cum functioneazã? Restricțiile Redux fac minuni.

Dezavantajele Redux

Cele trei reguli majore pe care Redux le aplică sunt o sabie cu două tăișuri. Acestea permit funcții puternice, dar provoacă în același timp dezavantaje inevitabile.

Curbă abruptă de învățare

Redux are o curbă de învățare relativ abruptă. Este nevoie de timp pentru a înțelege, a aminti și a te obișnui cu tiparele sale. Nu este recomandat să înveți Redux și React în același timp dacă ambele sunt noi pentru tine.

Cod „Boilerplate”.

În multe cazuri, folosirea Redux înseamnă a scrie mai mult cod. Este adesea necesar să atingeți mai multe fișiere pentru a funcționa o funcție simplă. Oamenii s-au plâns de codul „boilerplate” pe care ar trebui să-l scrie cu Redux.

Știu, asta sună contradictoriu. Nu am spus că Redux face posibilă implementarea funcțiilor cu cod minim ? Este un pic ca și cum ai folosi o mașină de spălat vase. În primul rând, ar trebui să petreci timpul aranjând cu grijă vasele în rânduri. Până atunci veți vedea beneficiile mașinii de spălat vase: economisirea timpului la curățarea efectivă a vaselor, igienizarea vaselor etc. Trebuie să decideți dacă timpul de pregătire merită!

Penalizare de performanță

Redux ar putea avea, de asemenea, un impact asupra performanței din cauza restricțiilor pe care le impune. Adaugă puțină suprasarcină ori de câte ori datele se schimbă. În cele mai multe cazuri, nu este mare lucru, iar încetinirea nu este vizibilă. Totuși, atunci când există o cantitate mare de date în magazin și când datele se schimbă frecvent (de exemplu, atunci când utilizatorul scrie rapid pe un dispozitiv mobil), interfața de utilizare poate deveni lent ca urmare.

Bonus: Redux nu este doar pentru React

O concepție greșită comună este că Redux este doar pentru React. Se pare că Redux nu poate face nimic fără React. Într-adevăr, Redux completează React în câteva moduri importante, așa cum am discutat mai devreme. Este cel mai frecvent caz de utilizare.

Cu toate acestea, de fapt, Redux poate funcționa cu orice framework front-end, cum ar fi Angular, Ember.js sau chiar jQuery, sau chiar JavaScript vanilla. Încercați să îl căutați pe google, veți găsi asta, asta, asta sau chiar asta. Ideile generale ale Redux se aplică oriunde!

Atâta timp cât folosești Redux cu înțelepciune, îi poți obține beneficiile în multe situații – nu doar într-o aplicație React.

Concluzie

Ca orice instrument, Redux oferă un compromis. Permite funcții puternice, dar are și dezavantaje inevitabile. Sarcina unei echipe de dezvoltare este să evalueze dacă compromisul merită și să ia o decizie conștientă.

În calitate de designeri, dacă înțelegem avantajele și dezavantajele Redux, vom putea contribui la această luare a deciziilor din perspectiva designului. De exemplu, poate am putea proiecta interfața de utilizare pentru a atenua impactul potențial asupra performanței? Poate că am putea susține includerea funcțiilor de anulare/refacere pentru a elimina o mulțime de dialoguri de confirmare? Poate că am putea sugera o interfață de utilizare optimistă, deoarece îmbunătățește experiența utilizatorului cu un cost relativ scăzut?

Înțelegeți beneficiile și limitările unei tehnologii și proiectați în consecință. Cred că asta a vrut să spună Steve Jobs prin „designul este modul în care funcționează”.