Tutorial React: componenti, hook e prestazioni

Pubblicato: 2022-03-11

Come è stato sottolineato nella prima parte del nostro tutorial su React, iniziare con React è relativamente facile. Inizia utilizzando Create React App (CRA), avvia un nuovo progetto e inizia a sviluppare. Purtroppo, nel tempo, potresti incontrare una situazione in cui il tuo codice diventerà piuttosto difficile da mantenere, specialmente se non conosci React. I componenti potrebbero diventare inutilmente grandi o potresti ritrovarti con elementi che potrebbero essere componenti ma non lo sono, quindi puoi finire per scrivere codice ripetitivo qua e là.

È qui che dovresti provare a iniziare davvero il tuo viaggio React, iniziando a pensare alle soluzioni di sviluppo React.

Ogni volta che ti avvicini a una nuova app, un nuovo design che devi trasformare in un'applicazione React in seguito, prova prima a decidere quali componenti saranno nel tuo schizzo, come puoi separare lo schizzo per renderli più facili da gestire e quali elementi sono ripetitivo (o almeno il loro comportamento). Cerca di evitare di aggiungere codice che potrebbe essere "utile in futuro": potrebbe essere allettante, ma quel futuro potrebbe non arrivare mai e manterrai quella funzione/componente generico extra che ha molte opzioni configurabili.

Tutorial React: illustrazione dei componenti React

Inoltre, se un componente è più lungo, diciamo 2-3 dell'altezza della finestra, forse vale la pena separarlo (se possibile), poiché sarà più facile leggerlo in seguito.

Componenti controllati e non controllati in reazione

Nella maggior parte delle applicazioni, è necessario un input e una qualche forma di interazione con gli utenti, che consenta loro di digitare qualcosa, caricare un file, selezionare un campo e così via. React si occupa dell'interazione dell'utente in due modi distinti: componenti controllati e non controllati .

Il valore dei componenti controllati, come suggerisce il nome, è controllato da React fornendo un valore all'elemento che interagisce con l'utente, mentre gli elementi non controllati non ottengono una proprietà value. Grazie a ciò, abbiamo un'unica fonte di verità che sembra essere lo stato Reagire, quindi non c'è discrepanza tra ciò che stiamo vedendo sullo schermo e ciò che abbiamo attualmente nel nostro stato. Lo sviluppatore deve passare una funzione che risponderà all'interazione dell'utente con un modulo, che ne cambierà lo stato.

 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}/> ); } }

Nei componenti React non controllati, non ci interessa come cambia il valore, ma se vogliamo conoscere il valore esatto, accediamo semplicemente tramite ref.

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

Quindi quale dovrebbe essere usato quando? Direi che i componenti controllati sono la strada da percorrere nella maggior parte dei casi, ma ci sono alcune eccezioni. Ad esempio, un caso in cui è necessario utilizzare componenti non controllati in React è l'input del tipo di file , poiché il suo valore è di sola lettura e non può essere impostato a livello di codice (è richiesta l'interazione dell'utente). Inoltre, trovo che i componenti controllati siano più facili da leggere e con cui lavorare. La convalida dei componenti controllati si basa sul rendering, lo stato può essere modificato e possiamo facilmente indicare che c'è qualcosa di sbagliato nell'input (ad esempio, formattazione o vuoto).

Rif

Abbiamo già menzionato refs , che sono una caratteristica speciale che era disponibile nei componenti di classe fino a quando gli hook non sono apparsi in 16.8.

I riferimenti possono fornire allo sviluppatore l'accesso a un componente React o a un elemento DOM (a seconda del tipo a cui alleghiamo il riferimento) tramite riferimento. È considerata una buona pratica cercare di evitarli e usarli solo in scenari indispensabili, poiché rendono il codice un po' più difficile da leggere e interrompono il flusso di dati dall'alto verso il basso. Tuttavia, ci sono casi in cui sono necessari, specialmente sugli elementi DOM (ad esempio, cambiare focus a livello di programmazione). Quando ti colleghi a un elemento componente di React, puoi usare liberamente i metodi all'interno di quel componente a cui ti riferisci. Tuttavia, questa pratica dovrebbe essere evitata poiché ci sono modi migliori per affrontarla (ad esempio, alzando lo stato e spostando le funzioni sui componenti principali).

I riferimenti hanno anche tre diversi modi in cui possono essere realizzati:

  • Usando una stringa letterale (legacy e dovrebbe essere evitata),
  • Utilizzando una funzione di callback impostata nell'attributo ref,
  • Creando ref come React.createRef() e associandolo a una proprietà di classe e accedendovi tramite (tenere presente che i riferimenti saranno disponibili dal ciclo di vita componentDidMount).

Infine, ci sono casi in cui i riferimenti non vengono passati e volte in cui vuoi accedere a un elemento di riferimento più profondo dal componente corrente (ad esempio, hai un componente <Button> che ha un elemento DOM <input> interno e in questo momento tu sono in un componente <Row> e dal componente di riga si desidera avere accesso per inserire la funzione focus DOM. Ecco dove forwardRef ).

Un caso in cui il riferimento non viene tramandato è quando c'è un componente di ordine superiore utilizzato su un componente: il motivo è abbastanza comprensibile in quanto ref NON è un oggetto di prop (simile a key ) quindi non viene tramandato, quindi lo farà fare riferimento HOC invece del componente che viene avvolto da esso. In tal caso, possiamo usare React.forwardRef che prende prop e ref come argomenti, che possono essere quindi assegnati a prop e passati al componente a cui vogliamo accedere.

 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} />; }); }

Limiti di errore

Più le cose diventano complesse, maggiore è la probabilità che qualcosa vada storto. Ecco perché i limiti di errore fanno parte di React. Quindi come lavorano?

Se qualcosa va storto e non c'è limite di errore come suo genitore, comporterà il fallimento dell'intera app React. È meglio non visualizzare le informazioni piuttosto che fuorviare gli utenti e visualizzare informazioni errate, ma non significa necessariamente che dovresti arrestare in modo anomalo l'intera applicazione e mostrare una schermata bianca. Con i limiti di errore, hai un ulteriore grado di flessibilità che puoi utilizzare. Puoi utilizzarne uno nell'intera app e visualizzare un messaggio di errore, oppure utilizzarlo in alcuni widget e semplicemente non visualizzarli, oppure visualizzare una piccola quantità di informazioni al posto di quei widget.

Ricorda che si tratta solo di problemi con il codice dichiarativo piuttosto che con il codice imperativo che scrivi per gestire alcuni eventi o chiamate. Per questi, dovresti comunque usare il normale approccio try/catch .

I limiti degli errori sono anche un luogo in cui è possibile inviare informazioni all'Error Logger in uso (nel metodo del ciclo di vita 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; } }

Componenti di ordine superiore

I componenti di ordine superiore (HOC) sono spesso menzionati in React e sono uno schema molto popolare, uno che probabilmente utilizzerai (o lo hai già fatto). Se hai familiarità con gli HOC, probabilmente hai visto withNavigation, connect, withRouter in molte librerie.

Gli HOC sono solo funzioni che prendono un componente come argomento e restituiranno un nuovo componente con capacità estese rispetto a quello senza il wrapper HOC. Grazie a ciò, puoi ottenere alcune funzioni facilmente estensibili che potrebbero potenziare i tuoi componenti (ad esempio, l'accesso alla navigazione). Gli HOC possono anche assumere alcune forme chiamate a seconda di ciò che abbiamo, l'unico argomento richiesto è sempre un componente, ma può richiedere argomenti aggiuntivi: alcune opzioni, o come in connect , prima invochi una funzione con configurazioni che in seguito restituisce una funzione che accetta un componente argomento e restituisce HOC.

Ci sono alcune cose che potresti aggiungere e dovresti evitare:

  • Aggiungi un nome visualizzato per la tua funzione HOC wrapper (quindi sai che è, in effetti, un HOC modificando il nome visualizzato del componente HOC).
  • Non utilizzare HOC all'interno di un metodo di rendering: dovresti già utilizzare un componente avanzato al suo interno, invece di creare un nuovo componente HOC a causa del rimontaggio continuo e della perdita del suo stato corrente.
  • I metodi statici non vengono copiati, quindi se vuoi avere alcuni metodi statici all'interno del tuo HOC appena creato, devi copiarli su te stesso.
  • I riferimenti menzionati non vengono passati, quindi usa React.forwardRef come React.forwardRef in precedenza per risolvere tali problemi.
 export function importantHoc() { return (Component) => class extends React.Component { importantFunction = () => { console.log("Very Important Function"); }; render() { return ( <Component {...this.props} importantFunction={this.importantFunction} /> ); } }; }

Messa in piega

Lo styling non è necessariamente correlato a React in sé, ma vale la pena menzionarlo per una serie di motivi.

Prima di tutto, i normali stili CSS/inline si applicano qui normalmente e puoi semplicemente aggiungere i nomi delle classi da CSS nell'attributo className e funzionerà correttamente. Lo stile inline è leggermente diverso dal normale stile HTML. La stringa non viene tramandata con stili ma piuttosto oggetti con valori corretti per ciascuno. Anche gli attributi di stile sono camelCased, quindi border-radius diventa borderRadius e così via.

Sembra che React abbia reso popolari alcune soluzioni che sono diventate comuni non solo in React, come i moduli CSS che sono stati recentemente integrati in CRA, dove puoi semplicemente importare name.modules.css e usare le sue classi come le proprietà per dare uno stile al tuo componente (alcuni IDE , ad esempio, WebStorm, ha anche il completamento automatico per quello, che ti dice quali nomi sono disponibili).

Un'altra soluzione che è anche popolare in React è CSS-in-JS (ad esempio, la libreria delle emotion ). Giusto per sottolineare ancora, i moduli CSS e le emozioni (o CSS-in-JS in generale) non si limitano a React.

Ganci in reazione

Gli hook sono probabilmente l'aggiunta più attesa a React dalla riscrittura. Il prodotto è all'altezza dell'hype? Dal mio punto di vista, sì, perché sono davvero un'ottima caratteristica. Sono essenzialmente funzioni che aprono nuove opportunità, come ad esempio:

  • Consente la rimozione di molti componenti di class che abbiamo usato solo perché non potevamo avere, ad esempio, uno stato locale o un riferimento, quindi il codice per un componente sembra più facile da leggere.
  • Consente di utilizzare meno codice per lo stesso effetto.
  • Rende le funzioni molto più facili da pensare e testare, ad esempio, utilizzando la libreria di test di reazione.
  • Può anche accettare parametri e il risultato di uno può essere facilmente utilizzato da un altro hook (ad esempio, setState da useState in useEffect ).
  • Minimizza molto meglio delle classi, che tendono ad essere un po' più problematiche per i minificatori.
  • Potrebbe rimuovere gli HOC e rendere i modelli di oggetti di scena nella tua app che hanno introdotto nuovi problemi nonostante siano stati progettati per risolverne altri.
  • Capace di essere costruito su misura da qualsiasi sviluppatore esperto di React.

Ci sono pochi hook React che sono inclusi come default. I tre di base sono useState , useEffect e useContext . Ce ne sono anche molti aggiuntivi, ad esempio useRef e useMemo , ma per ora ci concentreremo sulle basi.

Diamo un'occhiata a useState e usiamolo per creare un esempio di contatore semplice. Come funziona? Bene, in pratica, l'intero costrutto è davvero semplice e assomiglia a:

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

Viene richiamato con initialState (value) e restituisce un array con due elementi. Grazie all'assegnazione della destrutturazione dell'array, possiamo assegnare subito le variabili a questi elementi. Il primo è sempre l'ultimo stato dopo gli aggiornamenti, mentre l'altro è una funzione che utilizzeremo per aggiornare il valore. Sembra piuttosto facile, vero?

Inoltre, poiché tali componenti erano chiamati componenti funzionali senza stato, tale nome non è più appropriato, poiché possono avere uno stato come mostrato sopra. Quindi, i nomi dei componenti delle classi e dei componenti delle funzioni sembrano essere più in linea con ciò che effettivamente fanno, almeno da 16.8.0.

La funzione di aggiornamento (nel nostro caso setCounter ), può essere utilizzata anche come funzione che assumerà il valore precedente come argomento nella forma seguente:

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

Tuttavia, a differenza del componente della classe this.setState che stava eseguendo un'unione superficiale, l'impostazione della funzione ( setCounter nel nostro caso) sovrascrive invece l'intero stato.

Inoltre, initialState può anche essere una funzione, non solo un valore normale. Questo ha i suoi vantaggi, poiché quella funzione verrà eseguita solo durante il rendering iniziale del componente e successivamente non verrà più invocata.

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

Infine, se useremo setCounter con lo stesso identico valore che avevamo nello stesso momento nello stato corrente ( counter ), il componente non eseguirà il rendering.

D'altra parte, useEffect consiste nell'aggiungere effetti collaterali al nostro componente funzionale, che si tratti di abbonamenti, chiamate API, timer o qualsiasi cosa che potremmo trovare utile. Qualsiasi funzione che passeremo a useEffect verrà eseguita dopo il rendering e lo farà dopo ogni rendering a meno che non aggiungiamo una limitazione relativa a quali modifiche alle proprietà devono essere rieseguite come secondo argomento della funzione. Se vogliamo eseguirlo solo su mount e ripulire su unmount, dobbiamo solo passare un array vuoto al suo interno.

 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> ); };

Il codice precedente verrà eseguito solo una volta a causa di un array vuoto come secondo argomento. Fondamentalmente, è qualcosa di simile a componentDidMount in questo caso, ma si attiva un po' più tardi. Se vuoi avere un hook simile che viene chiamato prima del disegno del browser, usa useLayoutEffect , ma questi aggiornamenti verranno applicati in modo sincrono, a differenza useEffect .

useContext sembra essere il più facile da capire, poiché fornisce a quale contesto vogliamo accedere (un oggetto restituito dalla funzione createContext ) e in cambio ci fornisce il valore per quel contesto.

 const context = useContext(Context);

Infine, per scrivere il tuo hook, puoi semplicemente scrivere qualcosa di simile al seguente:

 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; }

Fondamentalmente, stiamo usando il normale hook useState per il quale stiamo assegnando come valore iniziale la larghezza della finestra. Quindi in useEffect, stiamo aggiungendo un listener che attiverà handleResize su ogni ridimensionamento della finestra. Cancelliamo anche dopo che il componente sarà smontato (guarda il ritorno in useEffect ). Facile?

Nota: la parola use in tutti gli hook è importante. Viene utilizzato perché consente a React di verificare se non si sta facendo qualcosa di male, ad esempio chiamare hook dalle normali funzioni JS.

Tipi di controllo

React aveva il proprio controllo degli oggetti di scena, prima che Flow e TypeScript fossero un'opzione.

PropTypes controlla se le proprietà (props) che vengono ricevute da un componente React e controlla se sono in linea con ciò che abbiamo. Ogni volta che si verifica una situazione diversa (ad esempio, un oggetto invece di un array), riceveremo un avviso nella console. È importante notare che i PropType vengono controllati solo in modalità di sviluppo a causa del loro impatto sulle prestazioni e del suddetto avviso della console.

A partire da React 15.5, PropTypes sono in un pacchetto diverso che deve essere installato separatamente. Sono dichiarati insieme alle proprietà in una proprietà statica chiamata propTypes (sorpresa), combinandoli con defaultProps che vengono utilizzati se le proprietà non sono definite ( undefined è l'unico caso). DefaultProps non sono correlati a PropTypes, ma possono risolvere alcuni avvisi che potrebbero apparire a causa di PropTypes.

Le altre due opzioni sono Flow e TypeScript e sono molto più popolari al giorno d'oggi (soprattutto TypeScript).

  • TypeScript è un superset tipizzato di JavaScript, sviluppato da Microsoft, che può controllare gli errori prima ancora che un'app sia in esecuzione e fornisce funzionalità di completamento automatico superiori per lo sviluppo. Migliora notevolmente anche il refactoring. Grazie al supporto Microsoft, che ha una vasta esperienza con le lingue digitate, è anche una scelta piuttosto sicura.
  • Flow non è un linguaggio, a differenza di TypeScript. È un controllo del tipo statico per JavaScript, quindi è più simile a uno strumento che includi in JavaScript che a un linguaggio. L'intera idea alla base di Flow è abbastanza simile a ciò che offre TypeScript. Ti consente di aggiungere tipi in modo che sia meno probabile che ci siano bug prima di eseguire il codice. Proprio come TypeScript, Flow è ora supportato in CRA (Create React App) dall'inizio.

Personalmente, trovo TypeScript più veloce (praticamente istantaneo), specialmente nel completamento automatico, che sembra un po' più lento con Flow. Vale la pena notare che IDE come WebStorm, che uso personalmente, utilizzano una CLI per l'integrazione con Flow. Tuttavia, sembra ancora più semplice integrare l'uso facoltativo nei file, in cui è sufficiente aggiungere // @flow all'inizio del file per avviare il controllo del tipo. Inoltre, da quello che posso dire, sembra che TypeScript abbia vinto la battaglia contro Flow alla fine: ora è molto più popolare e alcune delle librerie più popolari vengono refactoring da Flow a TypeScript.

Ci sono alcune altre opzioni, menzionate anche nella documentazione ufficiale, come Reason (sviluppato da Facebook e che sta guadagnando popolarità nella community di React), Kotlin (un linguaggio sviluppato da JetBrains) e altro ancora.

Ovviamente, per gli sviluppatori front-end, l'approccio più semplice sarebbe quello di entrare e iniziare a utilizzare Flow e TypeScript, piuttosto che passare a Kotlin o F#. Tuttavia, per gli sviluppatori back-end che stanno passando al front-end, potrebbe essere più facile iniziare con questi.

Produzione e prestazioni di reazione

La modifica più semplice e ovvia che devi fare per la modalità di produzione è passare a "produzione" per DefinePlugin e aggiungere UglifyJsPlugin nel caso di Webpack. Nel caso di CRA, è semplice come usare npm run build (che eseguirà react-scripts build ). Tieni presente che Webpack e CRA non sono le uniche opzioni, poiché puoi utilizzare altri strumenti di compilazione come Brunch. Questo di solito è coperto dalla documentazione ufficiale, che si tratti della documentazione ufficiale di React o della documentazione per uno strumento specifico. Per assicurarti che la modalità sia impostata correttamente, puoi utilizzare React Developer Tools, che ti darà un'indicazione sul tipo di build che stai utilizzando (produzione vs. sviluppo). I passaggi sopra menzionati faranno funzionare la tua applicazione senza controlli e avvisi che provengono da React e anche il pacchetto stesso sarà ridotto a icona.

Ci sono alcune altre cose che puoi fare per la tua app React. Cosa fai con il file JS che viene compilato? Puoi iniziare solo con "bundle.js" se la dimensione è relativamente piccola, o magari fare qualcosa come "fornitore + bundle" o forse "fornitore + parte più piccola richiesta + importare cose quando sono necessarie". Questo è utile quando hai a che fare con un'app molto grande e non è necessario importare tutto all'inizio. Tieni presente che il raggruppamento di codice JavaScript nel pacchetto principale che non viene nemmeno utilizzato aumenterà semplicemente le dimensioni del pacchetto e renderà l'app più lenta all'inizio.

I bundle del fornitore possono essere utili se stai pianificando di bloccare le versioni delle librerie dopo aver realizzato che potrebbero non cambiare per molto tempo (se mai). Inoltre, i file più grandi sono migliori per gzipping, quindi il vantaggio che ottieni dalla separazione a volte potrebbe non valerne la pena. Dipende dalla dimensione del file e a volte dovrai semplicemente provarlo da solo.

Divisione del codice

La suddivisione del codice può apparire in più modi di quanto suggerito qui, ma concentriamoci su ciò che abbiamo a disposizione in CRA e React stesso. Fondamentalmente, per dividere il codice in blocchi diversi, possiamo usare import() che funziona grazie a Webpack (l' import stessa è una proposta nella Fase 3 a partire da ora, quindi non fa ancora parte dello standard del linguaggio). Ogni volta che Webpack vede import , saprà che è necessario avviare la divisione del codice in questa fase e non può includerlo nel bundle principale (il codice che si trova all'interno dell'importazione).

Ora possiamo collegarlo con React.lazy() che richiede import() con un percorso di file contenente il componente che deve essere renderizzato in quel punto. Successivamente, possiamo utilizzare React.suspense() che visualizzerà un componente diverso in quella posizione fino a quando il componente importato non verrà caricato. Ci si potrebbe chiedere; se stiamo importando un singolo componente, perché ne avremmo bisogno?

Non è proprio così, poiché React.lazy() mostrerà il componente che import() , ma import() potrebbe recuperare un pezzo più grande di quel singolo componente. Ad esempio, quel particolare componente potrebbe avere altre librerie al seguito, più codice, ecc., quindi un file non è necessario: potrebbero essere molti più file raggruppati insieme. Infine, possiamo racchiudere tutto ciò in ErrorBoundary (puoi trovare il codice nella nostra sezione sui limiti degli errori) che servirà da fallback se qualcosa non riesce con il componente che volevamo importare (ad esempio, se c'è un errore di rete).

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

Questo è un esempio di base, ma ovviamente puoi fare di più. Puoi usare import e React.lazy per la suddivisione dinamica del percorso (ad es. amministratore rispetto a utente normale o semplicemente percorsi davvero grandi che portano molto). Tieni presente che React.lazy supporta solo le esportazioni predefinite al momento e non supporta il rendering lato server.

Reagire alle prestazioni del codice

Per quanto riguarda le prestazioni, se la tua applicazione React è in ritardo, ci sono due strumenti che possono aiutarti a capire il problema.

Il primo è Chrome Performance Tab, che ti dirà cosa succede con ciascun componente (ad esempio, montaggio, aggiornamento). Grazie a ciò, dovresti essere in grado di identificare quale componente presenta problemi di prestazioni e quindi ottimizzarlo.

L'altra opzione è usare DevTools Profiler che è diventato disponibile in React 16.5+ e, con la collaborazione di shouldComponentUpdate (o PureComponent, che è stato spiegato nella prima parte di questo tutorial), possiamo migliorare le prestazioni per alcuni componenti critici.

Ovviamente, l'utilizzo delle migliori pratiche di base per il Web è ottimale, come eliminare il rimbalzo di alcuni eventi (ad esempio, scorrere), essere cauti con le animazioni (usare la trasformazione invece di modificare l'altezza e animarla) e così via. L'uso delle migliori pratiche può essere trascurato molto facilmente, specialmente se stai appena facendo i conti con React.

Lo stato di reazione nel 2019 e oltre

Se dovessimo discutere del futuro di React, personalmente, non sarei troppo preoccupato. Dal mio punto di vista, React non avrà problemi a mantenere il suo trono nel 2019 e oltre.

React ha una posizione così forte, sostenuta da un vasto seguito di comunità, che sarà difficile detronizzarla. La community di React è fantastica, non sta finendo le idee e il team principale lavora costantemente per migliorare React, aggiungendo nuove funzionalità e risolvendo vecchi problemi. React è anche supportato da una grande azienda, ma i problemi di licenza sono scomparsi: al momento è autorizzato dal MIT.

Sì, ci sono alcune cose che dovrebbero essere cambiate o migliorate; per esempio, rendendo React un po' più piccolo (una delle misure menzionate è la rimozione di eventi sintetici) o rinominando className in class. Naturalmente, anche queste modifiche apparentemente minori potrebbero causare problemi come l'impatto sulla compatibilità del browser. Personalmente, mi chiedo anche cosa accadrà quando WebComponent guadagnerà più popolarità, poiché potrebbe aumentare alcune delle cose con cui React viene spesso utilizzato oggi. Non credo che saranno un vero sostituto, ma credo che potrebbero completarsi a vicenda.

Per quanto riguarda il breve termine, gli hook sono appena arrivati ​​su React. Questo è probabilmente il più grande cambiamento da quando la riscrittura è avvenuta in React, poiché apriranno molte possibilità e miglioreranno ulteriori componenti della funzione (e ora vengono davvero pubblicizzati).

Infine, poiché è quello che ho fatto più di recente, c'è React Native. Per me, è una grande tecnologia che è cambiata così tanto negli ultimi due anni (la mancanza di un collegamento nativo della reazione era probabilmente il problema più grande per la maggior parte delle persone e ovviamente c'erano molti bug). React Native sta riscrivendo il suo core, e ciò dovrebbe essere fatto in modo simile alla riscrittura di React (è tutto interno, niente o quasi nulla dovrebbe essere cambiato per gli sviluppatori). Rendering asincrono, un ponte più veloce e leggero tra nativo e JavaScript e altro ancora.

C'è molto da aspettarsi nell'ecosistema React, ma gli aggiornamenti di hook (e React Native se qualcuno ama i cellulari) sono probabilmente i cambiamenti più importanti che vedremo nel 2019.

Correlati: Recupero di dati obsoleti durante la riconvalida con React Hook: una guida