Tutorial de React: componentes, ganchos y rendimiento

Como se señaló en la primera parte de nuestro tutorial de React, comenzar con React es relativamente fácil. Comience usando Create React App (CRA), inicie un nuevo proyecto y comience a desarrollar. Lamentablemente, con el tiempo, puede llegar a una situación en la que su código se vuelva bastante difícil de mantener, especialmente si es nuevo en React. Los componentes pueden volverse innecesariamente grandes o podría terminar con elementos que podrían ser componentes pero no lo son, por lo que puede terminar escribiendo código repetitivo aquí y allá.

Ahí es donde debería intentar comenzar realmente su viaje React, comenzando a pensar en soluciones de desarrollo React.

Cada vez que se acerque a una nueva aplicación, un nuevo diseño que necesite transformar en una aplicación React más adelante, primero intente decidir qué componentes estarán en su boceto, cómo puede separar el boceto para que sea más fácil de administrar y qué elementos son repetitivo (o su comportamiento, al menos). Trate de evitar agregar código que pueda ser "útil en el futuro"; puede ser tentador, pero ese futuro podría nunca llegar y mantendrá esa función/componente genérico adicional que tiene muchas opciones configurables.

Además, si un componente es más largo que, digamos, 2 o 3 de la altura de la ventana, tal vez valga la pena separarlo (si es posible), ya que será más fácil leerlo más adelante.

Componentes controlados vs. no controlados en React

En la mayoría de las aplicaciones, existe la necesidad de ingresar y alguna forma de interacción con los usuarios, lo que les permite escribir algo, cargar un archivo, seleccionar un campo, etc. React se ocupa de la interacción del usuario de dos maneras distintas: componentes controlados y no controlados .

El valor de los componentes controlados, como su nombre indica, es controlado por React proporcionando un valor al elemento que interactúa con el usuario, mientras que los elementos no controlados no obtienen una propiedad de valor. Gracias a eso, tenemos una única fuente de verdad que resulta ser el estado React, por lo que no hay discrepancia entre lo que estamos viendo en la pantalla y lo que tenemos actualmente en nuestro estado. El desarrollador necesita pasar una función que responderá a la interacción del usuario con un formulario, lo que cambiará su estado.

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

En los componentes React no controlados, no nos importa cómo cambia el valor, pero si queremos saber el valor exacto, simplemente accedemos a él a través de la ref.

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

Entonces, ¿cuál debe usarse cuándo? Diría que los componentes controlados son el camino a seguir en la mayoría de los casos, pero hay algunas excepciones. Por ejemplo, un caso en el que necesita usar componentes no controlados en React es la entrada del tipo de file , ya que su valor es de solo lectura y no se puede configurar mediante programación (se requiere la interacción del usuario). Además, encuentro que los componentes controlados son más fáciles de leer y trabajar con ellos. Hacer la validación de los componentes controlados se basa en la representación, el estado se puede cambiar y podemos indicar fácilmente que hay algún problema con la entrada (por ejemplo, el formato o estar vacío).

referencias

Ya mencionamos refs , que son una característica especial que estaba disponible en los componentes de clase hasta que aparecieron los ganchos en 16.8.

Las referencias pueden dar acceso al desarrollador a un componente React o elemento DOM (dependiendo del tipo donde adjuntemos la referencia) a través de la referencia. Se considera una buena práctica tratar de evitarlos y usarlos solo en escenarios imprescindibles, ya que dificultan un poco la lectura del código y rompen el flujo de datos de arriba a abajo. Sin embargo, hay casos en los que son necesarios, especialmente en elementos DOM (p. ej., cambiar el enfoque programáticamente). Cuando se adjunta a un elemento de un componente de React, puede usar métodos libremente desde dentro de ese componente al que se refiere. Aún así, esta práctica debe evitarse ya que hay mejores formas de manejarla (por ejemplo, elevando el estado y moviendo las funciones a los componentes principales).

Los árbitros también tienen tres formas diferentes en que se pueden lograr:

• Usando un literal de cadena (heredado y debe evitarse),
• Usando una función de devolución de llamada que se está configurando en el atributo ref,
• Creando ref como React.createRef() y vinculándola a una propiedad de clase y accediendo a ella a través de ella (tenga en cuenta que las referencias estarán disponibles desde el ciclo de vida del componenteDidMount).

Finalmente, hay casos en los que las referencias no se transmiten y ocasiones en las que desea acceder a un elemento de referencia más profundo desde el componente actual (por ejemplo, tiene un componente <Button> que tiene un elemento DOM <input> interno y ahora mismo están en un componente <Row> , y desde el componente de fila al que desea tener acceso para ingresar la función de enfoque DOM. Ahí es donde usaría forwardRef ).

Un caso en el que la referencia no se transmite es cuando se usa un componente de orden superior en un componente; la razón es bastante comprensible, ya que ref NO es un prop (similar a key ), por lo que no se transmite. estar haciendo referencia al HOC en lugar de que el componente esté envuelto por él. En tal caso, podemos usar React.forwardRef que toma props y refs como argumentos, que luego pueden asignarse a prop y pasarse al componente al que queremos acceder.

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

Límites de error

Cuanto más complejas se vuelven las cosas, mayor es la probabilidad de que algo salga mal. Es por eso que los límites de error son parte de React. Asique, como trabajan?

Si algo sale mal y no hay un límite de error como padre, la aplicación React fallará por completo. Es mejor no mostrar información en lugar de engañar a los usuarios y mostrar información incorrecta, pero eso no significa necesariamente que deba bloquear toda la aplicación y mostrar una pantalla en blanco. Con los límites de error, tiene un grado adicional de flexibilidad que puede usar. Puede usar uno en toda la aplicación y mostrar un mensaje de error, o usarlo en algunos widgets y simplemente no mostrarlos, o mostrar una pequeña cantidad de información en lugar de esos widgets.

Recuerde que solo se trata de problemas con el código declarativo en lugar del código imperativo que escribe para manejar algunos eventos o llamadas. Para estos, aún debe usar el enfoque normal de intentar/atrapar .

Los límites de error también son un lugar donde puede enviar información al registrador de errores que utiliza (en el método de ciclo de vida de 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; } }

Componentes de orden superior

Los componentes de orden superior (HOC) a menudo se mencionan en React y son un patrón muy popular, uno que probablemente usará (o ya lo usó). Si está familiarizado con los HOC, probablemente haya visto withNavigation, connect, withRouter en muchas bibliotecas.

Los HOC son solo funciones que toman un componente como argumento y devolverán un nuevo componente con capacidades extendidas en comparación con el que no tiene el envoltorio HOC. Gracias a eso, puede lograr algunas funciones fácilmente extensibles que podrían mejorar sus componentes (por ejemplo, el acceso a la navegación). Los HOC también pueden tomar algunas formas llamadas según lo que tengamos, el único argumento siempre requerido es un componente, pero puede tomar argumentos adicionales: algunas opciones, o como en connect , primero invoca una función con configuraciones que luego devuelve una función que toma un componente de argumento y devuelve HOC.

Hay algunas cosas que podrías agregar y deberías evitar:

• Agregue un nombre para mostrar para su función HOC contenedora (para que sepa que, de hecho, es un HOC cambiando el nombre para mostrar del componente HOC).
• No use HOC dentro de un método de renderizado; ya debería estar usando un componente mejorado dentro de él, en lugar de crear un nuevo componente HOC allí debido a que lo vuelve a montar todo el tiempo y pierde su estado actual.
• Los métodos estáticos no se copian, por lo que si desea tener algunos métodos estáticos dentro de su HOC recién creado, debe copiarlos usted mismo.
• Las referencias mencionadas no se pasan, así que use React.forwardRef como se React.forwardRef anteriormente para resolver tales problemas.

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

Estilismo

El estilo no está necesariamente relacionado con React en sí, pero vale la pena mencionarlo por varias razones.

En primer lugar, los estilos regulares de CSS/en línea se aplican aquí normalmente y simplemente puede agregar nombres de clase de CSS en el atributo className, y funcionará correctamente. El estilo en línea es un poco diferente al estilo HTML normal. La cadena no se transmite con estilos sino con objetos con valores correctos para cada uno. Los atributos de estilo también están en formato camelCased, por lo que border-radius se convierte en borderRadius y así sucesivamente.

React parece haber popularizado algunas soluciones que se volvieron comunes no solo en React, como los módulos CSS que se integraron recientemente en CRA, donde simplemente puede importar name.modules.css y usar sus clases como propiedades para diseñar su componente (algunos IDE , por ejemplo, WebStorm, también tiene Autocompletar para eso, que le dice qué nombres están disponibles).

Otra solución que también es popular en React es CSS-in-JS (por ejemplo, la biblioteca de emotion ). Solo para señalar nuevamente, los módulos CSS y la emoción (o CSS-in-JS en general) no se limitan a React.

Ganchos en React

Los ganchos son posiblemente la adición más esperada a React desde la reescritura. ¿El producto está a la altura de las expectativas? Desde mi perspectiva, sí, ya que realmente son una gran característica. Son esencialmente funciones que abren nuevas oportunidades, tales como:

• Permite la eliminación de muchos componentes de class que solo usamos porque no podíamos tener, por ejemplo, un estado local o una referencia, por lo que el código de un componente parece más fácil de leer.
• Le permite usar menos código para el mismo efecto.
• Hace que las funciones sean mucho más fáciles de pensar y probar, por ejemplo, mediante el uso de la biblioteca de pruebas de reacción.
• También puede tomar parámetros, y el resultado de uno puede ser utilizado fácilmente por otro enlace (por ejemplo, setState de useState en useEffect ).
• Minimiza mucho mejor que las clases, que tienden a ser un poco más problemáticas para los minificadores.
• Podría eliminar HOC y renderizar patrones de accesorios en su aplicación que introdujeron nuevos problemas a pesar de haber sido diseñados para resolver otros.
• Capaz de ser construido a la medida por cualquier desarrollador experto de React.

Hay algunos enlaces de React que se incluyen de forma predeterminada. Los tres básicos son useState , useEffect y useContext . También hay varios adicionales, por ejemplo, useRef y useMemo , pero por ahora, nos centraremos en los conceptos básicos.

Echemos un vistazo a useState y usémoslo para crear un ejemplo de un contador sencillo. ¿Como funciona? Bueno, básicamente, toda la construcción es realmente sencilla y se ve así:

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

Se invoca con initialState (valor) y devuelve una matriz con dos elementos. Gracias a la asignación de desestructuración de matrices, podemos asignar las variables a estos elementos de inmediato. El primero es siempre el último estado después de las actualizaciones, mientras que el otro es una función que usaremos para actualizar el valor. Parece bastante fácil, ¿no?

Además, debido al hecho de que dichos componentes solían llamarse componentes funcionales sin estado, ese nombre ya no es apropiado, porque pueden tener un estado como el que se muestra arriba. Por lo tanto, los nombres de componentes de clase y componentes de función parecen estar más en línea con lo que realmente hacen, al menos desde 16.8.0.

La función de actualización (en nuestro caso, setCounter ), también se puede usar como una función que tomará el valor anterior como argumento de la siguiente forma:

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

Sin embargo, a diferencia del componente de la clase this.setState que estaba haciendo una combinación superficial, establecer la función ( setCounter en nuestro caso) anula todo el estado.

Además, initialState también puede ser una función, no solo un valor simple. Esto tiene sus propios beneficios, ya que esa función se ejecutará solo durante el renderizado inicial del componente y, después de eso, ya no se invocará.

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

Finalmente, si vamos a usar setCounter con exactamente el mismo valor que teníamos en el mismo momento en el estado actual ( counter ), entonces el componente no se volverá a representar.

Por otro lado, useEffect se trata de agregar efectos secundarios a nuestro componente funcional, ya sean suscripciones, llamadas API, temporizadores o cualquier cosa que podamos encontrar útil. Cualquier función que pasemos a useEffect se ejecutará después del renderizado, y lo hará después de cada renderizado a menos que agreguemos una limitación con respecto a qué cambios de propiedades se deben volver a ejecutar como un segundo argumento de la función. Si queremos ejecutarlo solo en el montaje y limpiarlo en el desmontaje, entonces solo necesitamos pasar una matriz vacía en él.

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

El código anterior solo se ejecutará una vez debido a una matriz vacía como segundo argumento. Básicamente, es algo así como componentDidMount en tal caso, pero se activa un poco más tarde. Si desea tener un enlace similar que se llame antes de la pintura del navegador, use useLayoutEffect , pero estas actualizaciones se aplicarán sincrónicamente, a diferencia de useEffect .

useContext parece ser el más fácil de entender, ya que proporciona a qué contexto queremos obtener acceso (un objeto que fue devuelto por la función createContext ) y, a cambio, nos proporciona el valor para ese contexto.

 const context = useContext(Context);

Finalmente, para escribir su propio gancho, puede escribir algo como lo siguiente:

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

Básicamente, estamos usando el enlace regular useState para el cual estamos asignando como valor inicial el ancho de la ventana. Luego, en useEffect, estamos agregando un oyente que activará handleResize en cada cambio de tamaño de ventana. También borramos después de que se desmonte el componente (mira el retorno en useEffect ). ¿Fácil?

Nota: La palabra uso en todos los ganchos es importante. Se usa porque le permite a React verificar si no está haciendo algo malo, por ejemplo, llamar a ganchos de funciones regulares de JS.

Tipos de comprobación

React tenía su propia verificación de accesorios, antes de que Flow y TypeScript fueran una opción.

PropTypes verifica si las propiedades (props) que recibe un componente React y verifica si están en línea con lo que tenemos. Cada vez que ocurra una situación diferente (por ejemplo, un objeto en lugar de una matriz), obtendremos una advertencia en la consola. Es importante tener en cuenta que PropTypes solo se verifican en el modo de desarrollo debido a su impacto en el rendimiento y la advertencia de la consola antes mencionada.

A partir de React 15.5, PropTypes están en un paquete diferente que debe instalarse por separado. Se declaran junto con propiedades en una propiedad estática llamada propTypes (sorpresa), combinándolos con defaultProps que se usan si las propiedades no están definidas ( undefined es el único caso). DefaultProps no están relacionados con PropTypes, pero pueden resolver algunas advertencias que pueden aparecer debido a PropTypes.

Las otras dos opciones son Flow y TypeScript, y son mucho más populares hoy en día (especialmente TypeScript).

• TypeScript es un superconjunto escrito de JavaScript, desarrollado por Microsoft, que puede verificar errores incluso antes de que una aplicación se ejecute y proporciona una funcionalidad superior de autocompletado para el desarrollo. También mejora enormemente la refactorización. Debido al soporte de Microsoft, que tiene una amplia experiencia con lenguajes escritos, también es una opción bastante segura.
• Flow no es un lenguaje, a diferencia de TypeScript. Es un verificador de tipo estático para JavaScript, por lo que es más parecido a una herramienta que incluye en JavaScript que a un lenguaje. Toda la idea detrás de Flow es bastante similar a lo que ofrece TypeScript. Le permite agregar tipos, por lo que es menos probable que haya errores antes de ejecutar el código. Al igual que TypeScript, Flow ahora es compatible con CRA (Crear aplicación React) desde el principio.

Personalmente, encuentro TypeScript más rápido (prácticamente instantáneo), especialmente en autocompletar, que parece un poco más lento con Flow. Vale la pena señalar que los IDE como WebStorm, que yo personalmente uso, emplean una CLI para la integración con Flow. Sin embargo, parece aún más fácil integrar el uso opcional en los archivos, donde simplemente agrega // @flow al principio del archivo para comenzar a verificar el tipo. Además, por lo que puedo decir, parece que TypeScript ganó la batalla contra Flow al final: ahora es mucho más popular, y algunas de las bibliotecas más populares se están refactorizando de Flow a TypeScript.

Hay algunas opciones más, mencionadas también en la documentación oficial, como Reason (desarrollado por Facebook y ganando popularidad en la comunidad React), Kotlin (un lenguaje desarrollado por JetBrains) y más.

Obviamente, para los desarrolladores front-end, el enfoque más sencillo sería incorporarse y comenzar a usar Flow y TypeScript, en lugar de cambiar a Kotlin o F#. Sin embargo, para los desarrolladores de back-end que están haciendo la transición a front-end, en realidad podría ser más fácil comenzar.

Rendimiento de producción y reacción

El cambio más básico y obvio que debe realizar para el modo de producción es cambiar a "producción" para DefinePlugin y agregar UglifyJsPlugin en el caso de Webpack. En el caso de CRA, es tan simple como usar npm run build (que ejecutará react-scripts build ). Tenga en cuenta que Webpack y CRA no son las únicas opciones, ya que puede usar otras herramientas de compilación como Brunch. Esto suele estar cubierto en la documentación oficial, ya sea la documentación oficial de React o la documentación de una herramienta específica. Para asegurarse de que el modo esté configurado correctamente, puede usar React Developer Tools, que le dará una indicación de qué tipo de compilación está usando (producción versus desarrollo). Los pasos mencionados anteriormente harán que su aplicación se ejecute sin controles y advertencias que provienen de React y el paquete en sí también se minimizará.

Hay algunas cosas más que puede hacer para su aplicación React. ¿Qué haces con el archivo JS que se construye? Puede comenzar simplemente con "bundle.js" si el tamaño es relativamente pequeño, o tal vez hacer algo como "proveedor + paquete" o tal vez "proveedor + parte requerida más pequeña + importar cosas cuando se necesiten". Esto es útil cuando se trata de una aplicación muy grande y no es necesario importar todo desde el principio. Tenga en cuenta que agrupar código JavaScript en el paquete principal que ni siquiera se está utilizando simplemente aumentará el tamaño del paquete y hará que la aplicación se cargue más lentamente desde el principio.

Los paquetes de proveedores pueden ser útiles si planea congelar las versiones de las bibliotecas al darse cuenta de que es posible que no cambien durante mucho tiempo (si es que lo hacen). Además, los archivos más grandes son mejores en gzip, por lo que el beneficio que obtiene al separarlos a veces puede no valer la pena. Depende del tamaño del archivo y, a veces, simplemente tendrá que probarlo usted mismo.

División de código

La división de código puede aparecer en más formas de las sugeridas aquí, pero concentrémonos en lo que tenemos disponible en CRA y React. Básicamente, para dividir el código en diferentes fragmentos, podemos usar import() que funciona gracias a Webpack (la import en sí es una propuesta en la Etapa 3 a partir de ahora, por lo que aún no es parte del lenguaje estándar). Siempre que Webpack vea import , sabrá que necesita comenzar a dividir el código en esta etapa y no puede incluirlo en el paquete principal (el código que está dentro de la importación).

Ahora podemos conectarlo con React.lazy() que requiere import() con una ruta de archivo que contenga el componente que se debe representar en ese lugar. A continuación, podemos usar React.suspense() que mostrará un componente diferente en ese lugar hasta que se cargue el componente importado. Uno podría preguntarse; si estamos importando un solo componente, ¿por qué lo necesitaríamos?

Ese no es exactamente el caso, ya que React.lazy() mostrará el componente que import() , pero import() podría obtener una porción más grande que ese único componente. Por ejemplo, ese componente en particular podría tener otras bibliotecas a cuestas, más código, etc., por lo que no es necesario un archivo; podría haber muchos más archivos agrupados. Finalmente, podemos envolver todo eso en ErrorBoundary (puede encontrar el código en nuestra sección sobre límites de error) que servirá como respaldo si algo falla con el componente que queríamos importar (por ejemplo, si hay un error de red).

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

Este es un ejemplo básico, pero obviamente puedes hacer más. Puede usar import y React.lazy para la división dinámica de rutas (por ejemplo, administrador frente a usuario normal, o simplemente rutas realmente grandes que aportan mucho). Tenga en cuenta que React.lazy solo admite exportaciones predeterminadas a partir de ahora y no admite la representación del lado del servidor.

Rendimiento del código de reacción

Con respecto al rendimiento, si su aplicación React está retrasada, existen dos herramientas que pueden ayudarlo a resolver el problema.

La primera es la pestaña Rendimiento de Chrome, que le indicará qué sucede con cada componente (por ejemplo, montaje, actualización). Gracias a eso, debería poder identificar qué componente presenta problemas de rendimiento y luego optimizarlo.

La otra opción es usar DevTools Profiler, que estuvo disponible en React 16.5+, y con la cooperación de shouldComponentUpdate (o PureComponent, que se explicó en la primera parte de este tutorial), podemos mejorar el rendimiento de algunos componentes críticos.

Obviamente, lo óptimo es emplear las mejores prácticas básicas para la web, como eliminar el rebote de algunos eventos (p. ej., desplazamiento), ser cauteloso con las animaciones (usar transformar en lugar de cambiar la altura y animarla), etc. El uso de las mejores prácticas se puede pasar por alto muy fácilmente, especialmente si recién se está familiarizando con React.

El estado de React en 2019 y más allá

Si tuviéramos que discutir el futuro de React, personalmente, no estaría demasiado preocupado. Desde mi perspectiva, React no tendrá problemas para mantener su trono en 2019 y más allá.

React tiene una posición tan sólida, respaldada por una gran comunidad de seguidores, que será difícil de destronar. La comunidad de React es excelente, no se está quedando sin ideas y el equipo central trabaja constantemente para mejorar React, agregando nuevas funciones y solucionando problemas antiguos. React también cuenta con el respaldo de una gran empresa, pero los problemas de licencias se han ido: ahora tiene la licencia del MIT.

Sí, hay algunas cosas que se espera que cambien o mejoren; por ejemplo, hacer que React sea un poco más pequeño (una de las medidas que se mencionaron es eliminar eventos sintéticos) o cambiar el nombre de className a class. Por supuesto, incluso estos cambios aparentemente menores podrían causar problemas, como afectar la compatibilidad del navegador. Personalmente, también me pregunto qué sucederá cuando WebComponent gane más popularidad, ya que podría aumentar algunas de las cosas con las que React se usa a menudo en la actualidad. No creo que sean un reemplazo absoluto, pero creo que podrían complementarse muy bien.

En cuanto al corto plazo, los ganchos acaban de llegar a React. Ese es probablemente el cambio más grande desde que ocurrió la reescritura en React, ya que abrirán muchas posibilidades y mejorarán más componentes de funciones (y ahora realmente están siendo promocionados).

Por último, como eso es lo que he estado haciendo más recientemente, está React Native. Para mí, es una gran tecnología que cambió mucho en los últimos años (la falta de un enlace nativo de reacción fue probablemente el mayor problema para la mayoría de las personas, y obviamente hubo muchos errores). React Native está reescribiendo su núcleo, y eso debe hacerse de manera similar a la reescritura de React (todo es interno, nada o casi nada debe cambiarse para los desarrolladores). Representación asíncrona, un puente más rápido y ligero entre nativo y JavaScript, y más.

Hay mucho que esperar en el ecosistema React, pero las actualizaciones de ganchos (y React Native si a alguien le encantan los móviles) son probablemente los cambios más importantes que veremos en 2019.