Tutorial React: componente, cârlige și performanță

După cum a fost subliniat în prima parte a tutorialului nostru React, începerea utilizării React este relativ ușoară. Începeți prin a utiliza Create React App (CRA), porniți un nou proiect și începeți să dezvoltați. Din păcate, în timp, s-ar putea să ajungeți într-o situație în care codul dvs. va deveni destul de greu de întreținut, mai ales dacă sunteți nou în React. Componentele pot deveni inutil de mari sau ați putea ajunge cu elemente care ar putea fi componente, dar nu sunt, așa că puteți ajunge să scrieți cod repetitiv ici și colo.

Acolo ar trebui să încercați să vă începeți cu adevărat călătoria React, începând să vă gândiți la soluțiile de dezvoltare React.

Ori de câte ori abordați o aplicație nouă, un design nou pe care trebuie să îl transformați într-o aplicație React mai târziu, încercați mai întâi să decideți ce componente vor fi în schița dvs., cum puteți separa schița pentru a le face mai ușor de gestionat și ce elemente sunt repetitive (sau comportamentul lor, cel puțin). Încercați să evitați să adăugați cod care ar putea fi „util în viitor” – ar putea fi tentant, dar acel viitor s-ar putea să nu vină niciodată și veți păstra acea funcție/componentă generică suplimentară care are o mulțime de opțiuni configurabile.

De asemenea, dacă o componentă este mai lungă decât, să zicem 2-3 înălțimea ferestrei, poate că merită separată (dacă este posibil) - pentru că va fi mai ușor de citit mai târziu.

Componente controlate vs. necontrolate în React

În majoritatea aplicațiilor, este nevoie de introducere și de o anumită formă de interacțiune cu utilizatorii, permițându-le să introducă ceva, să încarce un fișier, să selecteze un câmp și așa mai departe. React tratează interacțiunea utilizatorului în două moduri distincte - componente controlate și necontrolate .

Valoarea componentelor controlate, așa cum sugerează și numele lor, este controlată de React, oferind o valoare elementului care interacționează cu utilizatorul, în timp ce elementele necontrolate nu primesc o proprietate de valoare. Datorită acestui fapt, avem o singură sursă de adevăr care se întâmplă să fie starea React, deci nu există nepotrivire între ceea ce vedem pe ecran și ceea ce avem în prezent în starea noastră. Dezvoltatorul trebuie să treacă o funcție care va răspunde la interacțiunea utilizatorului cu un formular, care își va schimba starea.

 class ControlledInput extends React.Component { state = { value: "" }; onChange = (e) => this.setState({ value: e.target.value }); render() { return ( <input value={this.state.value} onChange={this.onChange}/> ); } }

În componentele React necontrolate, nu ne pasă de modul în care se schimbă valoarea, dar dacă vrem să știm valoarea exactă, pur și simplu o accesăm prin ref.

 class UncontrolledInput extends React.Component { input = React.createRef(); getValue = () => { console.log(this.input.current.value); }; render() { return ( <input ref={this.input}/> ); } }

Deci care ar trebui folosit când? Aș spune că componentele controlate sunt calea de urmat în majoritatea cazurilor, dar există câteva excepții. De exemplu, un caz în care trebuie să utilizați componente necontrolate în React este intrarea tipului de file , deoarece valoarea acestuia este doar pentru citire și nu poate fi setată programatic (este necesară interacțiunea utilizatorului). De asemenea, găsesc componentele controlate mai ușor de citit și mai ușor de lucrat. Efectuarea validării componentelor controlate se bazează pe redare, starea poate fi schimbată și putem indica cu ușurință că există ceva în neregulă cu intrarea (de exemplu, formatare sau gol).

Refs

Am menționat deja refs , care sunt o caracteristică specială care era disponibilă în componentele clasei până când hook-urile au apărut în 16.8.

Refs poate oferi dezvoltatorului acces la o componentă React sau la un element DOM (în funcție de tipul în care atașăm ref) prin referință. Este considerată o practică bună să încercați să le evitați și să le folosiți numai în scenarii obligatorii, deoarece fac codul puțin mai greu de citit și întrerupe fluxul de date de sus în jos. Cu toate acestea, există cazuri în care acestea sunt necesare, în special pentru elementele DOM (de exemplu, schimbarea focalizării în mod programatic). Când vă atașați la un element de componentă React, puteți utiliza liber metode din acea componentă la care vă referiți. Totuși, această practică ar trebui evitată, deoarece există modalități mai bune de a face față acesteia (de exemplu, ridicarea stării și mutarea funcțiilor către componentele părinte).

Refs au, de asemenea, trei moduri diferite în care pot fi realizate:

• Folosind un literal șir (moștenire și ar trebui evitată),
• Folosind o funcție de apel invers care este setată în atributul ref,
• Prin crearea ref ca React.createRef() și legându-l la o proprietate de clasă și accesând-o prin intermediul acesteia (ai grijă că referințele vor fi disponibile din ciclul de viață componentDidMount).

În cele din urmă, există cazuri în care referințele nu sunt transmise și momente în care doriți să accesați un element de referință mai profund din componenta curentă (de exemplu, aveți o componentă <Button> care are un element DOM <input> în interior și chiar acum sunt într-o componentă <Row> , iar din componenta rând doriți să aveți acces pentru a introduce funcția de focalizare DOM. Acolo ați folosi forwardRef ).

Un caz în care referința nu este transmisă este atunci când există o componentă de ordin superior utilizată pe o componentă - motivul este destul de înțeles deoarece ref NU este o prop (similar cu key ), așa că nu este transmisă, așa că va fi să facă referire la HOC în loc ca componenta să fie înfășurată de acesta. Într-un astfel de caz, putem folosi React.forwardRef care ia props și refers ca argumente, care pot fi apoi atribuite prop și transmise componentei pe care dorim să o accesăm.

 function withNewReference(Component) { class Hoc extends React.Component { render() { const {forwardedRef, ...props} = this.props; return <Component ref={forwardedRef} {...props}/>; } } return React.forwardRef((props, ref) => { return <Hoc {...props} forwardedRef={ref} />; }); }

Limite de eroare

Cu cât lucrurile devin mai complexe, cu atât este mai mare probabilitatea ca ceva să meargă prost. De aceea , limitele de eroare fac parte din React. Deci, cum funcționează?

Dacă ceva nu merge bine și nu există o limită de eroare ca părinte, va avea ca rezultat eșuarea întregii aplicații React. Este mai bine să nu afișați informații decât să induceți în eroare utilizatorii și să afișați informații greșite, dar nu înseamnă neapărat că ar trebui să blocați întreaga aplicație și să afișați un ecran alb. Cu limitele de eroare, aveți un grad suplimentar de flexibilitate pe care îl puteți utiliza. Puteți fie să utilizați unul în întreaga aplicație și să afișați un mesaj de eroare, fie să îl utilizați în unele widget-uri și pur și simplu să nu le afișați, fie să afișați o cantitate mică de informații în locul acelor widget-uri.

Amintiți-vă că este vorba doar despre probleme cu codul declarativ, mai degrabă decât codul imperativ, pe care le scrieți pentru gestionarea unor evenimente sau apeluri. Pentru acestea, ar trebui să utilizați în continuare abordarea obișnuită de încercare/prindere .

Limitele de eroare sunt, de asemenea, un loc în care puteți trimite informații către Error Logger -ul pe care îl utilizați (în metoda ciclului de viață componentDidCatch ).

 class ErrorBoundary extends React.Component { state = { hasError: false }; static getDerivedStateFromError(error) { return { hasError: true }; } componentDidCatch(error, info) { logToErrorLogger(error, info); } render() { if (this.state.hasError) { return <div>Help, something went wrong.</div>; } return this.props.children; } }

Componente de ordin superior

Componentele de ordin superior (HOC) sunt adesea menționate în React și sunt un model foarte popular, unul pe care probabil îl veți folosi (sau ați făcut-o deja). Dacă sunteți familiarizat cu HOC-urile, probabil ați văzut withNavigation, connect, withRouter în multe biblioteci.

HOC-urile sunt doar funcții care iau o componentă ca argument și vor returna o componentă nouă cu capabilități extinse în comparație cu cea fără wrapper-ul HOC. Datorită acestui fapt, puteți realiza câteva funcții ușor extensibile care ar putea îmbunătăți componentele (de exemplu, accesul la navigare). HOC-urile pot lua, de asemenea, câteva forme numite în funcție de ceea ce avem, singurul argument necesar fiind întotdeauna o componentă, dar poate lua argumente suplimentare - unele opțiuni sau, ca în connect , mai întâi invocați o funcție cu configurații care returnează ulterior o funcție care ia o componentă de argument și returnează HOC.

Există câteva lucruri pe care le puteți adăuga și ar trebui să le evitați:

• Adăugați un nume afișat pentru funcția Wrapper HOC (astfel încât să știți că este, de fapt, un HOC, schimbând numele afișat al componentei HOC).
• Nu utilizați HOC în cadrul unei metode de randare - ar trebui să utilizați deja o componentă îmbunătățită în interiorul acesteia, în loc să creați o nouă componentă HOC acolo, din cauza remontării acesteia tot timpul și a pierderii stării sale actuale.
• Metodele statice nu sunt copiate, așa că dacă doriți să aveți unele metode statice în interiorul HOC nou creat, trebuie să le copiați peste dvs.
• Refurile menționate nu sunt transmise, așa că utilizați React.forwardRef așa cum sa menționat anterior pentru a rezolva astfel de probleme.

 export function importantHoc() { return (Component) => class extends React.Component { importantFunction = () => { console.log("Very Important Function"); }; render() { return ( <Component {...this.props} importantFunction={this.importantFunction} /> ); } }; }

Styling

Stilul nu este neapărat legat de React în sine, dar merită menționat din mai multe motive.

În primul rând, stilurile obișnuite CSS/inline se aplică aici ca de obicei și puteți adăuga pur și simplu nume de clasă din CSS în atributul className și va funcționa corect. Stilul inline este puțin diferit de stilul HTML obișnuit. Șirul nu este transmis cu stiluri, ci mai degrabă obiecte cu valori corecte pentru fiecare. Atributele de stil sunt, de asemenea, camelCased, deci border-radius devine borderRadius și așa mai departe.

React pare să fi popularizat câteva soluții care au devenit obișnuite nu numai în React, cum ar fi modulele CSS care au fost integrate recent în CRA, unde puteți pur și simplu să importați name.modules.css și să folosiți clasele sale ca proprietăți pentru a vă stila componenta (unele IDE-uri). , de exemplu, WebStorm, au și completare automată pentru asta, care vă spune ce nume sunt disponibile).

O altă soluție care este, de asemenea, populară în React este CSS-in-JS (de exemplu, biblioteca de emotion ). Doar pentru a sublinia din nou, modulele CSS și emoția (sau CSS-in-JS în general) nu se limitează la React.

Cârlige în React

Cârligele sunt, probabil, cea mai așteptată adăugare la React de la rescriere. Produsul este la înălțimea hype-ului? Din perspectiva mea, da, deoarece sunt într-adevăr o caracteristică grozavă. Ele sunt în esență funcții care deschid noi oportunități, cum ar fi:

• Permite eliminarea multor componente ale class pe care le-am folosit doar pentru că nu am putut avea, de exemplu, o stare locală sau o referință, astfel încât codul pentru o componentă pare mai ușor de citit.
• Vă permite să utilizați mai puțin cod pentru același efect.
• Face funcțiile mult mai ușor de gândit și testat, de exemplu, prin utilizarea bibliotecii de testare-reacție.
• Poate lua, de asemenea, parametri, iar rezultatul unuia poate fi utilizat cu ușurință de un alt cârlig (de exemplu, setState din useState în useEffect ).
• Minimizează mult mai bine decât cursurile, care tind să fie puțin mai problematice pentru minificatori.
• S-ar putea să elimine HOC și să reda modele de recuzită în aplicația dvs., care a introdus noi probleme, deși au fost concepute pentru a le rezolva pe altele.
• Capabil să fie construit la comandă de către orice dezvoltator React calificat.

Există câteva cârlige React care sunt incluse implicit. Cele trei de bază sunt useState , useEffect și useContext . Există, de asemenea, câteva altele suplimentare, de exemplu, useRef și useMemo , dar pentru moment, ne vom concentra pe elementele de bază.

Să aruncăm o privire la useState și să-l folosim pentru a crea un exemplu de contor simplu. Cum functioneazã? Ei bine, practic, întreaga construcție este foarte simplă și arată astfel:

 export function Counter() { const [counter, setCounter] = React.useState(0); return ( <div> {counter} <button onClick={() => setCounter(counter + 1)}>+</button> </div> ); };

Este invocat cu initialState (valoare) și returnează o matrice cu două elemente împreună cu acesta. Datorită atribuirii de destructurare a matricei, putem aloca variabilele acestor elemente imediat. Prima este întotdeauna ultima stare după actualizări, în timp ce cealaltă este o funcție pe care o vom folosi pentru a actualiza valoarea. Pare destul de ușor, nu-i așa?

De asemenea, din cauza faptului că astfel de componente erau numite componente funcționale apatride, un astfel de nume nu mai este adecvat, deoarece pot avea o stare așa cum este arătată mai sus. Prin urmare, numele componente ale clasei și componente ale funcției par să fie mai în concordanță cu ceea ce fac de fapt, cel puțin din 16.8.0.

Funcția de actualizare (în cazul nostru setCounter ), poate fi folosită și ca funcție care va lua valoarea anterioară ca argument în următoarea formă:

 <button onClick={() => setCounter(prevCounter => prevCounter + 1)}>+</button> <button onClick={() => setCounter(prevCounter => prevCounter - 1)}>-</button>

Cu toate acestea, spre deosebire de componenta de clasă this.setState care făcea o îmbinare superficială, setarea funcției ( setCounter în cazul nostru) suprascrie în schimb întreaga stare.

În plus, initialState poate fi și o funcție, nu doar o valoare simplă. Acest lucru are propriile sale beneficii, deoarece acea funcție va fi rulată doar în timpul randării inițiale a componentei și după aceea, nu va mai fi invocată.

 const [counter, setCounter] = useState(() => calculateComplexInitialValue());

În cele din urmă, dacă vom folosi setCounter cu exact aceeași valoare pe care am avut-o în același moment în starea curentă ( counter ), atunci componenta nu se va reda.

Pe de altă parte, useEffect se referă la adăugarea de efecte secundare la componenta noastră funcțională, fie că este vorba de abonamente, apeluri API, temporizatoare sau aproape orice ne-am putea găsi util. Orice funcție pe care o vom trece la useEffect va fi rulată după randare și va face acest lucru după fiecare randare, cu excepția cazului în care adăugăm o limitare privind modificările proprietăților care ar trebui reluate ca al doilea argument al funcției. Dacă vrem să-l rulăm doar la montare și să curățăm la demontare, atunci trebuie doar să trecem o matrice goală în el.

 const fetchApi = async () => { const value = await fetch("https://jsonplaceholder.typicode.com/todos/1"); console.log(await value.json()); }; export function Counter() { const [counter, setCounter] = useState(0); useEffect(() => { fetchApi(); }, []); return ( <div> {counter} <button onClick={() => setCounter(prevCounter => prevCounter + 1)}>+</button> <button onClick={() => setCounter(prevCounter => prevCounter - 1)}>-</button> </div> ); };

Codul de mai sus va fi rulat o singură dată datorită unei matrice goale ca al doilea argument. Practic, este ceva de genul componentDidMount în acest caz, dar se declanșează puțin mai târziu. Dacă doriți să aveți un cârlig similar care este numit înainte de pictarea browserului, utilizați useLayoutEffect , dar aceste actualizări vor fi aplicate sincron, spre deosebire useEffect .

useContext pare să fie cel mai ușor de înțeles, deoarece unul oferă în ce context dorim să obținem acces (un obiect care a fost returnat de funcția createContext ) și, în schimb, ne oferă valoarea pentru acel context.

 const context = useContext(Context);

În cele din urmă, pentru a-ți scrie propriul cârlig, poți scrie ceva de genul următor:

 function useWindowWidth() { let [windowWidth, setWindowWidth] = useState(window.innerWidth); function handleResize() { setWindowWidth(window.innerWidth); } useEffect(() => { window.addEventListener('resize', handleResize); return () => window.removeEventListener('resize', handleResize); }, []); return windowWidth; }

Practic, folosim cârligul obișnuit useState pentru care îi atribuim ca valoare inițială lățimea ferestrei. Apoi, în useEffect, adăugăm un ascultător care va declanșa handleResize la fiecare redimensionare a ferestrei. De asemenea, ștergem după ce componenta va fi demontată (uitați-vă la returnarea în useEffect ). Uşor?

Notă: Cuvântul utilizare în toate cârligele este important. Este folosit pentru că permite React să verifice dacă nu faceți ceva rău, de exemplu, cârlige de apel din funcțiile JS obișnuite.

Verificarea tipurilor

React a avut propria verificare a elementelor de recuzită, înainte ca Flow și TypeScript să fie o opțiune.

PropTypes verifică dacă proprietățile (recuzitele) care sunt primite de o componentă React și verifică dacă sunt în conformitate cu ceea ce avem. Ori de câte ori apare o situație diferită (de exemplu, obiect în loc de matrice), vom primi un avertisment în consolă. Este important de reținut că PropTypes sunt verificate doar în modul de dezvoltare datorită impactului lor asupra performanței și avertismentului de consolă menționat mai sus.

Începând cu React 15.5, PropTypes sunt într-un pachet diferit care trebuie instalat separat. Ele sunt declarate de-a lungul proprietăților într-o proprietate statică numită propTypes (surpriză), combinându-le cu defaultProps care sunt folosite dacă proprietățile sunt nedefinite ( undefined este singurul caz). DefaultProps nu sunt legate de PropTypes, dar pot rezolva unele avertismente care ar putea apărea din cauza PropTypes.

Celelalte două opțiuni sunt Flow și TypeScript și sunt mult mai populare în zilele noastre (în special TypeScript).

• TypeScript este un superset tip de JavaScript, dezvoltat de Microsoft, care poate verifica erorile chiar înainte ca o aplicație să ruleze și oferă o funcționalitate superioară de completare automată pentru dezvoltare. De asemenea, îmbunătățește foarte mult refactorizarea. Datorită suportului Microsoft, care are o experiență vastă în limbajele tastate, este și o alegere destul de sigură.
• Flow nu este un limbaj, spre deosebire de TypeScript. Este un verificator de tip static pentru JavaScript, deci este mai asemănător cu un instrument pe care îl includeți în JavaScript decât cu o limbă. Întreaga idee din spatele Flow este destul de similară cu ceea ce oferă TypeScript. Vă permite să adăugați tipuri, astfel încât este mai puțin probabil să aveți erori înainte de a rula codul. La fel ca TypeScript, Flow este acum acceptat în CRA (Create React App) de la început.

Personal, mi se pare TypeScript mai rapid (practic instantaneu), mai ales la autocompletare, care pare ceva mai lent cu Flow. Este demn de remarcat faptul că IDE-urile precum WebStorm, pe care eu personal îl folosesc, folosesc un CLI pentru integrarea cu Flow. Cu toate acestea, pare și mai ușor să integrați utilizarea opțională în fișiere, unde pur și simplu adăugați // @flow la începutul fișierului pentru a începe verificarea tipului. De asemenea, din câte îmi pot da seama, se pare că TypeScript a câștigat lupta împotriva Flow în cele din urmă - este mult mai popular acum, iar unele dintre cele mai populare biblioteci sunt refactorizate de la Flow la TypeScript.

Mai sunt câteva opțiuni, menționate și în documentația oficială, precum Reason (dezvoltat de Facebook și câștigând popularitate în comunitatea React), Kotlin (un limbaj dezvoltat de JetBrains) și multe altele.

Evident, pentru dezvoltatorii front-end, cea mai ușoară abordare ar fi să intri și să începi să folosești Flow și TypeScript, mai degrabă decât să treci la Kotlin sau F#. Cu toate acestea, pentru dezvoltatorii back-end care trec la front-end, acestea ar putea fi de fapt mai ușor de început.

Performanță de producție și reacție

Cea mai simplă și evidentă modificare pe care trebuie să o faceți pentru modul de producție este să treceți la „producție” pentru DefinePlugin și să adăugați UglifyJsPlugin în cazul Webpack. În cazul CRA, este la fel de simplu ca utilizarea npm run build (care va rula react-scripts build ). Rețineți că Webpack și CRA nu sunt singurele opțiuni, deoarece puteți utiliza alte instrumente de construcție, cum ar fi Brunch. Acest lucru este de obicei acoperit în documentația oficială, fie că este documentația oficială React sau documentația pentru un anumit instrument. Pentru a vă asigura că modul este setat corect, puteți utiliza React Developer Tools, care vă va oferi o indicație despre tipul de construcție pe care îl utilizați (producție vs. dezvoltare). Pașii menționați mai sus vor face ca aplicația să ruleze fără verificări și avertismente care vin de la React, iar pachetul în sine va fi, de asemenea, redus la minimum.

Mai sunt câteva lucruri pe care le puteți face pentru aplicația dvs. React. Ce faci cu fișierul JS care este construit? Puteți începe doar cu „bundle.js” dacă dimensiunea este relativ mică sau poate faceți ceva de genul „furnizor + pachet” sau poate „furnizor + cea mai mică parte necesară + importați lucruri atunci când sunt necesare”. Acest lucru este util atunci când aveți de-a face cu o aplicație foarte mare și nu trebuie să importați totul de la început. Rețineți că gruparea unor coduri JavaScript în pachetul principal care nici măcar nu este utilizat va crește pur și simplu dimensiunea pachetului și va face ca aplicația să se încarce mai încet de la început.

Pachetele de furnizori pot fi utile dacă intenționați să înghețați versiunile bibliotecilor când vă dați seama că s-ar putea să nu se schimbe pentru o lungă perioadă de timp (dacă vreodată). De asemenea, fișierele mai mari sunt mai bune la gzipping, astfel încât beneficiul pe care îl obțineți din separare ar putea uneori să nu merite. Depinde de dimensiunea fișierului și uneori va trebui pur și simplu să îl încercați singur.

Divizarea codului

Divizarea codului poate apărea în mai multe moduri decât este sugerat aici, dar să ne concentrăm pe ceea ce avem disponibil în CRA și React în sine. Practic, pentru a împărți codul în diferite bucăți, putem folosi import() care funcționează datorită Webpack ( import în sine este o propunere în Etapa 3, deci nu face parte încă din standardul de limbă). Ori de câte ori Webpack vede import , va ști că trebuie să înceapă divizarea codului în această etapă și nu îl poate include în pachetul principal (codul care se află în interiorul importului).

Acum îl putem conecta cu React.lazy() care necesită import() cu o cale de fișier care conține componenta care trebuie redată în acel loc. Apoi, putem folosi React.suspense() care va afișa o componentă diferită în acel loc până când componenta importată este încărcată. S-ar putea întreba cineva; dacă importăm o singură componentă, atunci de ce am avea nevoie de ea?

Nu este chiar așa, deoarece React.lazy() va arăta componenta pe care o import() , dar import() ar putea aduce o bucată mai mare decât acea singură componentă. De exemplu, acea componentă specială ar putea avea alte biblioteci, mai mult cod etc., astfel încât un fișier nu este necesar - ar putea fi multe mai multe fișiere grupate împreună. În cele din urmă, putem include toate acestea în ErrorBoundary (puteți găsi codul în secțiunea noastră despre limitele erorilor) care va servi ca o rezervă dacă ceva nu reușește cu componenta pe care am vrut să o importam (de exemplu, dacă există o eroare de rețea).

 import ErrorBoundary from './ErrorBoundary'; const ComponentOne = React.lazy(() => import('./ComponentOne')); function MyComponent() { return ( <ErrorBoundary> <React.Suspense fallback={<div>Loading...</div>}> <ComponentOne/> </React.Suspense> </ErrorBoundary> ); }

Acesta este un exemplu de bază, dar, evident, puteți face mai mult. Puteți folosi import și React.lazy pentru împărțirea dinamică a rutei (de exemplu, administrator vs. utilizator obișnuit sau doar căi foarte mari care aduc multe). Rețineți că React.lazy acceptă doar exporturile implicite de acum și nu acceptă randarea pe server.

React Code Performance

În ceea ce privește performanța, dacă aplicația dvs. React acționează cu întârziere, există două instrumente care vă pot ajuta să înțelegeți problema.

Primul este Chrome Performance Tab, care vă va spune ce se întâmplă cu fiecare componentă (de exemplu, montare, actualizare). Datorită acestui fapt, ar trebui să puteți identifica ce componentă prezintă probleme de performanță și apoi să o optimizați.

Cealaltă opțiune este să folosiți DevTools Profiler, care a devenit disponibil în React 16.5+ și, cu cooperarea cu shouldComponentUpdate (sau PureComponent, care a fost explicat în prima parte a acestui tutorial), putem îmbunătăți performanța pentru unele componente critice.

În mod evident, folosirea celor mai bune practici de bază pentru web este optimă, cum ar fi eliminarea unor evenimente (de exemplu, derulare), prudență cu animațiile (folosirea transformării în loc de modificarea înălțimii și animarea acesteia) și așa mai departe. Utilizarea celor mai bune practici poate fi trecută cu vederea foarte ușor, mai ales dacă abia vă apropiați de React.

Starea de React în 2019 și mai departe

Dacă ar fi să discutăm despre viitorul lui React, personal, nu aș fi prea îngrijorat. Din perspectiva mea, React nu va avea probleme în a-și păstra tronul în 2019 și mai departe.

React are o poziție atât de puternică, susținută de o mulțime de urmăritori ai comunității, încât va fi dificil de detronat. Comunitatea React este grozavă, nu rămâne fără idei, iar echipa principală lucrează constant pentru a îmbunătăți React, adăugând noi funcții și remediand problemele vechi. React este, de asemenea, susținut de o companie uriașă, dar problemele de licențiere au dispărut – este licențiat MIT chiar acum.

Da, există câteva lucruri care se așteaptă să fie schimbate sau îmbunătățite; de exemplu, făcând React mai mic (una dintre măsurile care au fost menționate este eliminarea evenimentelor sintetice) sau redenumirea className în class. Desigur, chiar și aceste modificări aparent minore ar putea cauza probleme precum impactul compatibilității browserului. Personal, mă întreb și ce se va întâmpla când WebComponent câștigă mai multă popularitate, deoarece ar putea spori unele dintre lucrurile cu care React este adesea folosit astăzi. Nu cred că vor fi un înlocuitor de-a dreptul, dar cred că s-ar putea completa reciproc frumos.

În ceea ce privește pe termen scurt, cârligele tocmai au venit la React. Aceasta este probabil cea mai mare schimbare de când s-a produs rescrierea în React, deoarece acestea vor deschide o mulțime de posibilități și vor îmbunătăți componentele suplimentare ale funcției (și sunt cu adevărat încurajate acum).

În cele din urmă, deoarece asta am făcut cel mai recent, există React Native. Pentru mine, este o tehnologie grozavă care s-a schimbat atât de mult în ultimii doi ani (lipsa unei legături native de reacție a fost probabil cea mai mare problemă pentru majoritatea oamenilor și, evident, au existat o mulțime de erori). React Native este rescris de bază și asta ar trebui făcut într-un mod similar cu rescrierea React (totul este intern, nimic sau aproape nimic nu ar trebui schimbat pentru dezvoltatori). Redare asincronă, o punte mai rapidă și mai ușoară între nativ și JavaScript și multe altele.

Sunt multe de așteptat în ecosistemul React, dar actualizările hook-urilor (și React Native dacă cineva iubește telefoanele mobile) sunt probabil cele mai importante schimbări pe care le vom vedea în 2019.