DEV Community: Christian Caracach

Por qué necesitás React Query

Christian Caracach — Mon, 13 Nov 2023 01:37:48 +0000

Ésta es una traducción del post Why You Want React Query de Dominik Dorfmeister(TkDodo) - 07.11.2023

No es ningún secreto que me encanta React Query por cómo simplifica la forma en que interactuamos con el estado asíncrono en nuestras aplicaciones React. Y sé que muchos colegas desarrolladores sienten lo mismo.

A veces, sin embargo, me encuentro con publicaciones que afirman que no necesitas utilizarlo para hacer algo tan "simple" como obtener datos de un servidor.

No necesitamos todas las funciones adicionales que React Query ofrece, así que no queremos agregar una biblioteca de terceros cuando podemos simplemente realizar una búsqueda de datos en un useEffect de manera igualmente sencilla.

Hasta cierto punto, creo que es un punto válido: React Query te proporciona muchas funciones como almacenamiento en caché, reintentos, sondeos, sincronización de datos, precarga, ... y alrededor de un millón más que irían mucho más allá del alcance de este artículo. Está bien si no los necesitas, pero aún así creo que esto no debería impedirte usar React Query.

Frameworks
Si estás utilizando un marco de trabajo que tiene una solución incorporada para la obtención y mutación de datos, es posible que no necesites React Query.

Entonces, en lugar de eso, analicemos el ejemplo estándar de realizar una búsqueda en un useEffect que surgió recientemente en Twitter y profundicemos en por qué podría ser una buena idea utilizar React Query también en esas situaciones:

fetch-in-useEffect

function Bookmarks({ category }) {
  const [data, setData] = useState([])
  const [error, setError] = useState()

  useEffect(() => {
    fetch(`${endpoint}/${category}`)
      .then(res => res.json())
      .then(d => setData(d))
      .catch(e => setError(e))
  }, [category])

  // Return JSX based on data and error state
}

Si crees que este código es adecuado para casos de uso simples donde no necesitas funciones adicionales, permíteme decirte que identifiqué de inmediato 🐛 5 errores 🪲 escondidos en estas 10 líneas de código.

Quizás tómate uno o dos minutos y ve si puedes encontrarlos todos. Esperaré...

Pista: No es el conjunto de dependencias. Eso está bien.

1- Condición de Carrera 🏎
Hay razones por las cuales la documentación oficial de Reactt recomienda usar un framework o una biblioteca como React Query para la obtención de datos. Mientras que realizar la solicitud de búsqueda puede ser un ejercicio bastante trivial, hacer que ese estado esté disponible de manera predecible en tu aplicación ciertamente no lo es.

El efecto está configurado de manera que se vuelve a buscar cada vez que cambia la categoría, lo cual es ciertamente correcto. Sin embargo, las respuestas de la red pueden llegar en un orden diferente al que las enviaste. Así que si cambias la categoría de libros a películas y la respuesta de películas llega antes que la respuesta de libros, terminarás con datos incorrectos en tu componente.

Al final, te quedará un estado inconsistente: tu estado local indicará que has seleccionado películas, pero los datos que estás representando son en realidad de libros.

La documentación de React dice que podemos solucionar esto con una función de limpieza y un booleano de ignorar, así que hagámoslo:

ignore-flag

function Bookmarks({ category }) {
  const [data, setData] = useState([])
  const [error, setError] = useState()

  useEffect(() => {
    let ignore = false
    fetch(`${endpoint}/${category}`)
      .then(res => res.json())
      .then(d => {
        if (!ignore) {
          setData(d)
        }
      .catch(e => {
        if (!ignore) {
          setError(e)
        }
      })
      return () => {
        ignore = true
      }
  }, [category])

  // Return JSX based on data and error state
}

Lo que sucede ahora es que la función de limpieza del efecto se ejecuta cuando cambia la categoría, estableciendo la bandera local de "ignorar" en true. Si después de eso llega una respuesta de búsqueda, ya no llamará a setState. Muy fácil.

2- Estado de carga 🕐
No está presente en absoluto. No tenemos forma de mostrar una interfaz de usuario pendiente mientras se realizan las solicitudes, ni para la primera ni para las solicitudes posteriores. Entonces, ¿agreguemos eso?

loading-state

function Bookmarks({ category }) {
  const [isLoading, setIsLoading] = useState(true)
  const [data, setData] = useState([])
  const [error, setError] = useState()

  useEffect(() => {
    let ignore = false
    setIsLoading(true)
    fetch(`${endpoint}/${category}`)
      .then(res => res.json())
      .then(d => {
        if (!ignore) {
          setData(d)
        }
      .catch(e => {
        if (!ignore) {
          setError(e)
        }
      })
      .finally(() => {
        if (!ignore) {
          setIsLoading(false)
        }
      })
      return () => {
        ignore = true
      }
  }, [category])

  // Return JSX based on data and error state
}

3- Estado vacío 🗑️
Inicializar los datos con un array vacío parece una buena idea para evitar tener que verificar indefiniciones(undefined) todo el tiempo, pero ¿qué pasa si recuperamos datos para una categoría que aún no tiene entradas, y de hecho recibimos un array vacío? No tendríamos forma de distinguir entre "sin datos aún" y "ningún dato en absoluto". El estado de carga que acabamos de introducir ayuda, pero aún es mejor inicializar con indefinido(undefined):

empty-state

function Bookmarks({ category }) {
  const [isLoading, setIsLoading] = useState(true)
  const [data, setData] = useState()
  const [error, setError] = useState()

  useEffect(() => {
    let ignore = false
    setIsLoading(true)
    fetch(`${endpoint}/${category}`)
      .then(res => res.json())
      .then(d => {
        if (!ignore) {
          setData(d)
        }
      .catch(e => {
        if (!ignore) {
          setError(e)
        }
      })
      .finally(() => {
        if (!ignore) {
          setIsLoading(false)
        }
      })
      return () => {
        ignore = true
      }
  }, [category])

  // Return JSX based on data and error state
}

4- Los datos y el error no se reinician cuando cambia la categoría 🔄
Tanto los datos como el error son variables de estado separadas, y no se reinician cuando cambia la categoría. Esto significa que si una categoría falla y cambiamos a otra que se recupera con éxito, nuestro estado será:

data: datosDeLaCategoriaActual
error: errorDeLaCategoriaAnterior

El resultado dependerá de cómo rendericemos JSX en función de este estado. Si verificamos primero el error, renderizaremos la interfaz de usuario de error con el mensaje antiguo, aunque tengamos datos válidos:

error-first

return (
  <div>
    { error ? (
      <div>Error: {error.message}</div>
    ) : (
      <ul>
        {data.map(item => (
          <li key={item.id}>{item.name}</div>
        ))}
      </ul>
    )}
  </div>
)

Si verificamos primero los datos, tenemos el mismo problema si la segunda solicitud falla. Si siempre renderizamos tanto el error como los datos, también estamos mostrando información potencialmente desactualizada. 😔

Para solucionar esto, debemos restablecer nuestro estado local cuando cambia la categoría:

reset-state

function Bookmarks({ category }) {
  const [isLoading, setIsLoading] = useState(true)
  const [data, setData] = useState()
  const [error, setError] = useState()

  useEffect(() => {
    let ignore = false
    setIsLoading(true)
    fetch(`${endpoint}/${category}`)
      .then(res => res.json())
      .then(d => {
        if (!ignore) {
          setData(d)
          setError(undefined)
        }
      .catch(e => {
        if (!ignore) {
          setError(e)
          setData(undefined)
        }
      })
      .finally(() => {
        if (!ignore) {
          setIsLoading(false)
        }
      })
      return () => {
        ignore = true
      }
  }, [category])

  // Return JSX based on data and error state
}

5- Se ejecutará dos veces en StrictMode 🔥🔥
Bueno, esto es más una molestia que un error, pero definitivamente es algo que sorprende a los nuevos desarrolladores de React. Si tu aplicación está envuelta en , React llamará intencionalmente tu efecto dos veces en el modo de desarrollo para ayudarte a encontrar errores como funciones de limpieza faltantes.

Si quisiéramos evitar eso, tendríamos que agregar otra "solución de contorno con ref", lo cual no creo que valga la pena.

Bonus: Manejo de errores 🚨
No incluí esto en la lista original de errores porque tendrías el mismo problema con React Query: fetch no rechaza los errores HTTP, así que tendrías que verificar res.ok y lanzar un error tú mismo.

error-handling

function Bookmarks({ category }) {
  const [isLoading, setIsLoading] = useState(true)
  const [data, setData] = useState()
  const [error, setError] = useState()

  useEffect(() => {
    let ignore = false
    setIsLoading(true)
    fetch(`${endpoint}/${category}`)
      .then(res => {
        if (!res.ok) {
          throw new Error('Failed to fetch')
        }
        return res.json()
      })
      .then(d => {
        if (!ignore) {
          setData(d)
          setError(undefined)
        }
      .catch(e => {
        if (!ignore) {
          setError(e)
          setData(undefined)
        }
      })
      .finally(() => {
        if (!ignore) {
          setIsLoading(false)
        }
      })
      return () => {
        ignore = true
      }
  }, [category])

  // Return JSX based on data and error state
}

Por qué Fetch no rechaza las respuestas de error
Si deseas obtener más información sobre por qué fetch se comporta de esa manera, echa un vistazo a este excelente artículo de Artem Zakharchenko.

Nuestro pequeño useEffect hook de "solo queremos obtener datos, ¿qué tan difícil puede ser?" se convirtió en un gran desorden de código espagueti 🍝 tan pronto como tuvimos que considerar casos especiales y la gestión del estado. Entonces, ¿cuál es la lección aquí?

La obtención de datos es simple.
La gestión asíncrona del estado no lo es.
Y aquí es donde entra React Query, porque React Query NO es una biblioteca de obtención de datos, es un gestor de estado asíncrono. Entonces, cuando dices que no lo necesitas para hacer algo tan simple como obtener datos de un punto final, en realidad tienes razón: incluso con React Query, necesitas escribir el mismo código de obtención que antes.

Pero aún lo necesitas para hacer que ese estado esté disponible de manera predecible en tu aplicación de la manera más fácil posible. Porque seamos honestos, no escribí ese código de booleano de ignorar antes de usar React Query, y probablemente tú tampoco lo hiciste. 😉

Con React Query, el código anterior se convierte en:

react-query

function Bookmarks({ category }) {
  const { isLoading, data, error } = useQuery({
    queryKey: ['bookmarks', category],
    queryFn: () =>
      fetch(`${endpoint}/${category}`).then((res) => {
        if (!res.ok) {
          throw new Error('Failed to fetch')
        }
        return res.json()
      }),
  })

  // Return JSX based on data and error state
}

Esto abarca aproximadamente el 50% del código espagueti mencionado anteriormente, y más o menos la misma cantidad que el fragmento original y con errores. Y sí, esto aborda automáticamente todos los errores que encontramos:

🐛 Errores
🏎️ No hay condición de carrera porque el estado siempre se almacena según su entrada (categoría).
🕐 Obtienes estados de carga, datos y error de forma gratuita, incluyendo uniones discriminadas a nivel de tipo.
🗑️ Los estados vacíos están claramente separados y se pueden mejorar aún más con funciones como placeholderData.
🔄 No obtendrás datos ni errores de una categoría anterior a menos que optes por ello.
🔥 Las múltiples solicitudes se deduplican de manera eficiente, incluidas aquellas provocadas por StrictMode.

Entonces, si aún piensas que no quieres usar React Query, me gustaría desafiarte a probarlo en tu próximo proyecto. Apuesto a que no solo terminarás con un código más resistente a casos especiales, sino también más fácil de mantener y ampliar. Y una vez que pruebes todas las funciones que ofrece, es probable que nunca mires hacia atrás.

Query.gg 🔮
He estado trabajando en un nuevo curso oficial sobre React Query junto con ui.dev. Este curso te brindará una comprensión de los principios fundamentales tanto de cómo funciona React Query bajo el capó como de cómo escribir código de React Query que escala. Si te gusta el contenido que he estado creando hasta ahora, te encantará query.gg.

Bonus: Cancelación
Muchas personas en Twitter mencionaron la falta de cancelación de solicitudes en el fragmento original. No creo que eso sea necesariamente un error, solo una característica faltante. Por supuesto, React Query también tiene esto cubierto con un cambio bastante sencillo:

cancelation

function Bookmarks({ category }) {
  const { isLoading, data, error } = useQuery({
    queryKey: ['bookmarks', category],
    queryFn: ({ signal }) =>
      fetch(`${endpoint}/${category}`, { signal }).then((res) => {
        if (!res.ok) {
          throw new Error('Failed to fetch')
        }
        return res.json()
      }),
  })

  // Return JSX based on data and error state
}

Simplemente toma la señal que recibes en queryFn, pásala a fetch y las solicitudes se abortarán automáticamente cuando cambie la categoría. 🎉

Eso es todo por hoy. No dudes en contactarme en Twitter si tienes alguna pregunta, o simplemente deja un comentario abajo. ⬇️

ReactJs vs React Native: Resumen, diferencias clave, ventajas y desventajas

Christian Caracach — Fri, 06 Oct 2023 20:31:53 +0000

Ésta es una traducción del post ReactJs vs React Native: Overview, key difference, pros and cons de Yevhen Cheshchevyi - 22.01.2022

React es una de las bibliotecas de JavaScript más populares para construir aplicaciones web. Es utilizada por grandes empresas de tecnología de todo el mundo, incluyendo Instagram, Facebook, Netflix y otros. React Native es un framework basado en React que ayuda a construir aplicaciones móviles multiplataforma.

Según la encuesta anual de StackOverflow, un recurso importante para programadores, React ocupa el segundo lugar en una lista de los frameworks más populares entre los desarrolladores web. Supera ampliamente a sus competidores directos, Vue.js y Angular.js.

¿Qué es React.js?

React.js es una biblioteca de JavaScript para construir aplicaciones web que cambian su estado sin recargar las páginas. Es una solución perfecta para construir interfaces de usuario complejas con una gran cantidad de contenido dinámico que se transforma a medida que los usuarios interactúan con los elementos de la página.

En 2011, el ingeniero de Facebook Jordan Valke creó FaxJs, un prototipo de React. El código fuente de la biblioteca se hizo público en 2013. Desde entonces, React ha evolucionado desde una herramienta prometedora para optimizar aplicaciones web hasta convertirse en un componente de desarrollo indispensable.

Una de sus principales características es que una aplicación impulsada por React puede renderizarse tanto en el lado del servidor como en el lado del cliente cuando sea necesario. Cuando los desarrolladores de React idearon un mecanismo para simplificar la renderización en el lado del servidor, la biblioteca ganó popularidad. Este enfoque ayuda a crear aplicaciones de alto rendimiento con una buena optimización.

Beneficios de React.js

Uno de los principales beneficios de React.js es que hace que el desarrollo sea más eficiente al permitir que el programador controle el ciclo de representación de los componentes de la aplicación. React es ideal para crear una interfaz dinámica que responde rápidamente a las acciones del usuario.

La primera característica importante de React es un enfoque declarativo activamente utilizado. Un desarrollador puede describir el comportamiento de los elementos en función de ciertas acciones realizadas por un usuario y, de esta manera, controlar el flujo, en contraposición al enfoque imperativo.

El segundo principio es la utilización de componentes. Una interfaz se compone de "bloques de construcción" que se pueden transformar según se desee. Un programador describe los componentes utilizando la sintaxis JSX, que es similar a HTML pero se considera más legible que JavaScript.

El tercer elemento clave es el DOM virtual, lo que significa que durante el trabajo, la interacción se realiza con una copia más ligera del DOM. Cuando es necesario actualizar el árbol DOM, se compara con la copia virtual y solo se representan los elementos alterados. Para los usuarios, esto se traduce en una representación más rápida y un menor consumo de recursos del dispositivo.

React es utilizado por muchas empresas grandes para construir poderosas aplicaciones web que pueden ser constantemente mejoradas y mantenidas a lo largo del tiempo.

Beneficios clave de React desde la perspectiva del cliente:

Alto rendimiento. Los elementos cambian su estado al instante ya que el sistema actualiza objetos específicos en lugar de toda la página.
Reutilización de componentes. Los desarrolladores pueden tomar elementos necesarios de bibliotecas de terceros de componentes predefinidos y ensamblar una interfaz bloque por bloque. Esto incluye elementos de diseño de materiales de Material-UI, componentes del framework de Bootstrap de React-Bootstrap y muchos otros. Esto es beneficioso para los clientes, ya que los programadores gastan menos tiempo construyendo la interfaz de usuario.
Mantener los beneficios de las aplicaciones clásicas. La mayoría de los frameworks modernos ofrecen renderización en el lado del servidor. React puede imitar el comportamiento disponible en las aplicaciones clásicas por defecto, lo cual es positivo.
Trabajar con una gran cantidad de componentes. Si es necesario, una aplicación web basada en React puede optimizarse para manejar grandes cantidades de datos, aunque requerirá bastante tiempo.
Un gran número de herramientas de automatización. Los desarrolladores tienen ESLint para encontrar errores en el código JS, un conjunto de herramientas proporcionado por React Testing Library para pruebas, etc.
La principal ventaja de usar React desde un punto de vista empresarial es su alta popularidad. No es un problema encontrar un desarrollador, y también es posible reemplazar al contratista si es necesario. Un nuevo programador entenderá la esencia del producto, analizará el enfoque del colega y se pondrá en marcha.

Trampas y desafíos

Si un cliente necesita un sitio con un gran número de páginas y planea promocionarlo en los motores de búsqueda, elegir React como núcleo conducirá inevitablemente a la necesidad de la renderización en el servidor. Esto complica el desarrollo y afecta el costo final del proyecto.

Al mismo tiempo, React tiene una documentación bien diseñada. Está respaldado por una comunidad activa de desarrolladores, que es una de las más grandes del mundo. Los miembros de la comunidad siempre están dispuestos a ayudar, y las soluciones para las tareas más comunes se describen en recursos populares.

Otra desventaja está asociada con un pequeño número de componentes no estándar. Si necesita algo complicado, tendrá que crearlo usted mismo. Y el tiempo de desarrollo aumentará significativamente si hay muchos de estos componentes incluidos en la interfaz.

Las bibliotecas de componentes de React son tanto una pérdida como una ganancia. Los desarrolladores deben integrar cada "bloque de construcción" en un "edificio terminado"; es decir, no se trata solo de agregar algunos "ladrillos" nuevos, sino de convertirlos en parte de un gran ecosistema. A veces, esto lleva mucho tiempo.

El principal inconveniente es que React es simplemente un conjunto de componentes diferentes. Los desarrolladores pueden elegir su propio conjunto de tecnología, y cada una de las herramientas vendrá con ventajas y desventajas.

¿Qué es React Native?

React Native es un marco para el desarrollo de aplicaciones móviles multiplataforma, basado en React.js. Es un producto creado por programadores de Facebook y puesto a disposición de la comunidad en 2015.

Los programadores que conocen JavaScript y la sintaxis de React pueden dominar fácilmente el marco y construir aplicaciones para teléfonos inteligentes tanto en Android como en iOS sin necesidad de dividir la tarea en múltiples equipos de desarrollo.

Vale la pena señalar en esta reseña de React Native que una aplicación consta de dos elementos principales: el núcleo de JS y una parte nativa que se ejecutan en paralelo.

Beneficios de React Native

La principal ventaja de React Native es su núcleo en forma de React, aunque la interfaz se muestra como si estuviera creada con la ayuda de herramientas nativas para Android e iOS. Los usuarios no notarán la diferencia entre aplicaciones basadas en Swift y React Native.

Muchos gigantes de la tecnología utilizan RN para combinar código con soluciones nativas. Una parte del código puede escribirse en Java para Android o Swift para iOS e integrarse en el código de React Native.

La diferencia global entre React y React Native es que el primero crea el DOM en un navegador, mientras que RN se integra en la arquitectura de aplicaciones móviles basadas en Android e iOS.

Los principales beneficios desde una perspectiva empresarial son:

Enorme popularidad. React Native se hizo público hace solo seis años, pero desde entonces han aparecido muchos componentes que simplifican el desarrollo.
Desarrollo simultáneo. El cliente recibe una aplicación para dos de los principales sistemas operativos móviles de una sola vez. No es necesario pagar por dos equipos separados.
Nivel de productividad suficiente. Las aplicaciones basadas en React Native están a la par con sus contrapartes nativas cuando se trata de productos con funcionalidad básica.
Arquitectura modular. Permite dividir una aplicación en módulos intercambiables, lo que hace que el proceso de creación de un producto sea universal.

El análisis instantáneo de cambios, el tiempo reducido de actualización de aplicaciones y otros beneficios hacen de React Native una de las mejores herramientas para construir productos para Android e iOS.

Trampas y Desventajas

RN es adecuado para aplicaciones con lógica compleja que requieren integración con el hardware del dispositivo, pero solo si participan desarrolladores que utilizan tecnologías nativas. Si necesita importar contactos o utilizar Bluetooth, puede usar una biblioteca nativa para eso de la comunidad de RN, sin embargo, cuando se necesita personalización, será bastante difícil implementarla sin conocer la parte nativa. Sin embargo, no hay una mejor alternativa que RN cuando se necesitan interfaces rápidas basadas en API predefinidas.

Además de lo anterior, React Native tiene varias otras desventajas, a saber, aplicaciones grandes. Si crea productos basados en bibliotecas nativas para Android e iOS, el archivo de instalación será menos intensivo en recursos. Esto se debe a que RN agrega sus propios assets al paquete de la aplicación.

El principal riesgo para las empresas es la falta de estabilidad garantizada. Google y Apple proporcionan soporte a largo plazo para aplicaciones construidas con bibliotecas nativas. Sin embargo, si Facebook deja de invertir en React Native, un producto impulsado por RN puede dejar de funcionar.

Comparar React Native vs. React.js solo tiene sentido si un cliente no comprende cuál es la opción adecuada para un proyecto en particular. Estas son herramientas relacionadas que resuelven el mismo problema de diferentes maneras. El marco de JS está diseñado para crear aplicaciones web, y RN está dirigido al desarrollo para dispositivos móviles.

React.js reúne tecnología y React Native puede formar parte de aplicaciones con código nativo. Sin embargo, la integración de RN en una aplicación nativa es relevante principalmente para empresas grandes o proyectos específicos. En este escenario, se realizarán cálculos complejos utilizando funciones del sistema, mientras que la representación de la interfaz de usuario se realizará mediante React.

React Query y React Context

Christian Caracach — Mon, 28 Aug 2023 00:26:34 +0000

Ésta es una traducción del post "React Query and React Context" de Dominik Dorfmeister (TkDodo) - 22.07.2023

Una de las mejores características de React Query es que puedes usar una consulta donde quieras en tu árbol de componentes: Tu componente puede obtener sus propios datos, colocados en el mismo lugar donde los necesitas:

function ProductTable() {
  const productQuery = useProductQuery()

  if (productQuery.data) {
    return <table>...</table>
  }

  if (productQuery.isError) {
    return <ErrorMessage error={productQuery.error} />
  }

  return <SkeletonLoader />
}

Para mí, esto es genial porque hace que el ProductTable esté desacoplado e independiente, es responsable de leer sus propias dependencias: los datos de los productos. Si ya están en la caché, perfecto, simplemente los leeremos. Si no es así, iremos a buscarlos. Y podemos ver patrones similares surgir con los Componentes del Servidor de React. Ellos también nos permiten obtener datos directamente dentro de nuestros componentes. Ya no hay divisiones arbitrarias entre componentes con estado y sin estado, o entre componentes inteligentes y tontos.

Poder obtener datos directamente en un componente, donde lo necesitas, es inmensamente útil. Literalmente podemos tomar el componente ProductTable y moverlo a cualquier lugar de nuestra aplicación, y simplemente funcionará. El componente es muy resistente al cambio, que es la razón principal por la cual abogo por acceder a tu consulta directamente donde sea necesario (a través de un hook personalizado), tanto en el punto 10: React Query como gestor de estado, como en el punto 21: Pensando en React Query.

Sin embargo, no es una solución infalible, ya que conlleva compromisos. Esto no debería ser sorprendente, porque al final del día, todo implica compromisos. Pero, ¿qué estamos intercambiando exactamente aquí?

Siendo autosuficiente

Para que un componente sea autónomo, significa que debe manejar casos en los que los datos de la consulta no están disponibles todavía, en particular: los estados de carga y error. Esto no es un gran problema para nuestro componente , porque muy a menudo, cuando se carga por primera vez, en realidad mostrará ese .

Pero hay muchas otras situaciones en las que solo queremos leer información de algunas partes de nuestra consulta, donde sabemos que la consulta ya se ha utilizado más arriba en el árbol. Por ejemplo, podríamos tener una userQuery que contiene información sobre el usuario que ha iniciado sesión:

export const useUserQuery = (id: number) => {
  return useQuery({
    queryKey: ['user', id],
    queryFn: () => fetchUserById(id),
  })
}
export const useCurrentUserQuery = () => {
  const id = useCurrentUserId()

  return useUserQuery(id)
}

Probablemente utilizaremos esta consulta bastante temprano en nuestro árbol de componentes, para verificar qué derechos tiene el usuario que ha iniciado sesión, y esto podría determinar si realmente podemos ver la página o no. Es información esencial que queremos en todas partes de nuestra página.

Ahora más abajo en el árbol, podríamos tener un componente que quiera mostrar el nombre de usuario, que podemos obtener del gancho useCurrentUserQuery:

function UserNameDisplay() {
  const { data } = useCurrentUserQuery()
  return <div>User: {data.userName}</div>
}

Por supuesto, TypeScript no nos dejará hacerlo, porque los datos podrían ser potencialmente indefinidos. Pero nosotros ya sabemos: no puede ser indefinido, porque en nuestra situación, UserNameDisplay no se renderizará sin que la consulta ya se haya iniciado más arriba en el árbol.

Ese es un pequeño dilema. ¿Queremos simplemente silenciar a TS aquí y hacer data!.userName, porque sabemos que estará definido? ¿Optamos por la seguridad y hacemos data?.userName (lo cual es posible aquí, pero puede no ser tan fácil de lograr en otras situaciones)? ¿Agregamos simplemente una protección: if (!data) return null? ¿O añadimos manejo adecuado de carga y errores a las 25 ubicaciones en las que llamamos a useCurrentUserQuery?

Para ser honesto, creo que todas esas formas son un tanto subóptimas. No quiero llenar mi base de código con comprobaciones que "nunca deberían ocurrir" (según mi conocimiento actual). Pero tampoco quiero ignorar TypeScript, porque (como es habitual), TS tiene razón.

Una dependencia implícita

Nuestro problema surge del hecho de que tenemos una dependencia implícita: una dependencia que solo existe en nuestra mente, en nuestro conocimiento de la estructura de la aplicación, pero que no es visible en el propio código.

A pesar de que sabemos que podemos llamar con seguridad a useCurrentUserQuery sin tener que comprobar si los datos no están definidos, ningún análisis estático puede verificar esto. Nuestros compañeros de trabajo podrían no saberlo. Yo mismo podría no saberlo dentro de 3 meses.

La parte más peligrosa es que podría ser cierto ahora, pero podría dejar de serlo en el futuro. Podemos decidir renderizar otra instancia de UserNameDisplay en algún lugar de nuestra aplicación, donde es posible que no tengamos datos de usuario en la caché, o donde podríamos tener datos de usuario en la caché condicionalmente, por ejemplo, si hemos visitado una página diferente antes.

Esto es completamente opuesto al componente : en lugar de ser resistente al cambio, se vuelve propenso a errores en las refactorizaciones. No esperaríamos que el componente UserNameDisplay se rompiera solo porque movemos algunos componentes aparentemente no relacionados...

Hacerlo explícito

La solución es, por supuesto, hacer que la dependencia sea explícita. Y no hay mejor manera de hacerlo que con React Context:

Contexto de React

Existe un mito bastante extendido sobre el Contexto de React, así que aclaremos esto: No, el Contexto de React no es un administrador de estado. Puede convertirse en una solución aparentemente buena para la gestión de estado cuando se combina con useState o useReducer, pero para ser honesto, nunca me ha gustado realmente este enfoque, ya que he tenido situaciones problemáticas como estas demasiado a menudo:

// Detect dark theme var iframe = document.getElementById('tweet-1495072479118864398-326'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1495072479118864398&theme=dark" }

Entonces, lo más probable es que estés mejor utilizando una herramienta dedicada. Mark Erikson, el mantenedor de Redux y autor de publicaciones de blog muy extensas, tiene un buen artículo sobre ese tema: Respuestas en Blog: Por qué el Contexto de React no es una herramienta de "gestión de estado" (y por qué no reemplaza a Redux).

Mi tuit ya lo menciona: el Contexto de React es una herramienta de inyección de dependencias. Te permite definir qué "cosas" necesita tu componente para funcionar, y cualquier componente padre es responsable de proporcionar esa información.

Esto es conceptualmente lo mismo que el prop-drilling, que es el proceso de pasar props a través de múltiples capas. El Contexto te permite hacer lo mismo: tomar algunos valores y pasarlos como props a los hijos, excepto que puedes evitar algunas capas:

Con el contexto, simplemente te saltas al intermediario. En nuestro ejemplo de useCurrentUserQuery, puede ayudarnos a hacer que esa dependencia sea explícita: en lugar de leer useCurrentUserQuery directamente en todos los componentes donde queremos evitar la comprobación de disponibilidad de datos, lo leemos desde el Contexto de React. Y ese contexto será llenado por el componente padre que realmente realiza la primera comprobación:

const CurrentUserContext = React.CreateContext<User | null>(null)

export const useCurrentUserContext = () => {
  return React.useContext(CurrentUserContext)
}

export const CurrentUserContextProvider = ({
  children,
}: {
  children: React.ReactNode
}) => {
  const currentUserQuery = useCurrentUserQuery()

  if (currentUserQuery.isLoading) {
    return <SkeletonLoader />
  }

  if (currentUserQuery.isError) {
    return <ErrorMessage error={currentUserQuery.error} />
  }

  return (
    <CurrentUserContext.Provider value={currentUserQuery.data}>
      {children}
    </CurrentUserContext.Provider>
  )
}

Aquí, tomamos la currentUserQuery y colocamos los datos resultantes en el Contexto de React, si existen (eliminando los estados de carga y error de antemano). Luego podemos leer desde ese contexto de manera segura en nuestros componentes hijos, por ejemplo, en el componente UserNameDisplay:

function UserNameDisplay() {
  const data = useCurrentUserContext()
  return <div>User: {data.username}</div>
}

Con eso, hemos convertido nuestra dependencia implícita (sabemos que los datos se han obtenido más arriba en el árbol) en una dependencia explícita. Siempre que alguien vea UserNameDisplay, sabrá que necesitan tener los datos proporcionados desde CurrentUserContextProvider. Esto es algo que puedes tener en cuenta al refactorizar. Si cambias dónde se renderiza el Proveedor, también sabrás que afectará a todos los componentes hijos que utilicen ese contexto. Esto es algo que no puedes saber cuando un componente solo utiliza una consulta, porque las consultas suelen ser globales en toda tu aplicación, y los datos podrían o no existir.

Agradando a TypeScript

A pesar de todo, TypeScript aún no estará muy contento, porque el Contexto de React está diseñado para funcionar incluso sin un Proveedor, en cuyo caso te proporcionará el valor predeterminado del Contexto, que en nuestro caso es nulo. Dado que nunca queremos que useCurrentUserContext funcione en una situación en la que estemos fuera de un Proveedor, podemos agregar una invariante a nuestro hook personalizado:

export const useCurrentUserContext = () => {
  const currentUser = React.useContext(CurrentUserContext)
  if (!currentUser) {
    throw new Error('CurrentUserContext: No value provided')
  }

  return currentUser
}

Este método asegura que fallaremos de manera rápida y con un buen mensaje de error si alguna vez accedemos accidentalmente a useCurrentUserContext en el lugar equivocado. Y con esto, TypeScript inferirá el valor "User" para nuestro hook personalizado, por lo que podemos usarlo de manera segura y acceder a sus propiedades.

Sincronización de Estado

Podrías estar pensando: ¿No es esto una "sincronización de estado" - copiar un valor de React Query y ponerlo en otro método de distribución de estado?

La respuesta es: ¡No, no lo es! La única fuente de verdad sigue siendo la consulta (query). No hay forma de cambiar el valor de contexto aparte del Proveedor (Provider), que siempre reflejará los datos más recientes que tiene la consulta. Nada se copia aquí y nada puede desincronizarse. Pasar datos desde React Query como una propiedad (prop) a un componente hijo tampoco es una "sincronización de estado", y dado que el contexto es similar a la transmisión de propiedades (prop drilling), tampoco es una "sincronización de estado".

Cascadas de Solicitudes

Nada está exento de desventajas, y esta técnica tampoco lo está. Específicamente, podría crear cascadas de solicitudes en la red, ya que el árbol de componentes se detendrá en su renderización (se "suspende") en el Proveedor (Provider), por lo que los componentes secundarios no se renderizarán y no podrán realizar solicitudes a la red, incluso si no están relacionados.

Principalmente consideraría este enfoque para los datos que son obligatorios para mi sub-árbol: la información del usuario es un buen ejemplo, ya que de todos modos podríamos no saber qué renderizar sin esos datos.

Suspense

Hablando sobre Suspense: Sí, puedes lograr una arquitectura similar con React Suspense, y sí, tiene la misma desventaja: posibles cascadas de solicitudes, de las cuales ya he hablado en el punto #17: Alimentando la Caché de Consultas (Query Cache).

Un problema es que en la versión principal actual (v4), usar "suspense: true" en tu consulta (query) no estrechará el tipo de datos, porque todavía hay formas de desactivar la consulta y evitar que se ejecute.

Sin embargo, en la versión v5, habrá un gancho explícito llamado "useSuspenseQuery", donde los datos están garantizados para estar definidos una vez que el componente se renderiza. Con eso, podemos hacer:

function UserNameDisplay() {
  const { data } = useSuspenseQuery(...)
  return <div>User: {data.username}</div>
}

y TypeScript estará contento al respecto. 🎉

Cómo “Reactcionar” - Kent C. Dodds - 3.11.2021

Christian Caracach — Mon, 21 Aug 2023 00:49:18 +0000

Ésta es una traducción del post original How To React por Kent C. Dodds.

La mejor manera de aprender React es… honestamente, es diferente para todos. Pero aquí hay algunos consejos útiles de alguien que le ha enseñado React a decenas (¿cientos?) de miles de desarrolladores/as.

Abstracción

Empecemos hablando acerca de la Abstracción. Aquí hay un ejemplo de abstracción de youmightnotneedjquery.com:

// $(el).toggleClass(className);

function toggleClass(el, className) {
  if (el.classList) {
    el.classList.toggle(className)
  } else {
    var classes = el.className.split(' ')
    var existingIndex = -1
    for (var i = classes.length; i--; ) {
      if (classes[i] === className) existingIndex = i
    }

    if (existingIndex >= 0) {
      classes.splice(existingIndex, 1)
    } else {
      classes.push(className)
    }

    el.className = classes.join(' ')
  }
}

Muy útil. Pero aquí está el truco … Si tu no necesitas darle soporte a IE8, entonces puedes cambiar ésto:

// $(el).toggleClass(className)

function toggleClass(el, className) {
  el.classList.toggle(className)
}

Lo que, honestamente, es una abstracción que no debería existir en absoluto… el.classList.toggle(className) es suficiente en sí mismo.

Así que, ésto es lo que necesitás saber sobre una abstracción antes de usarlo en el flujo de trabajo de tu aplicación:

¿Cuál es el beneficio de ésta abstracción?

¿Cuál es el costo de ésta abstracción?

Si no sabés éstas cosas, entonces corrés el riesgo de pagar el costo de solucionar un problema que no tenés. ¡Un costo sin beneficio no es negocio!

Una parte importante de entender los costos y beneficios es “sentir” el dolor del problema que ésta abstracción resuelve. Por eso es importante aprender React y su ecosistema en el orden correcto para estar seguro de que no no estás sobrepasado por aprender demasiado al mismo tiempo y usar las abstracciones efectivamente.

Para mas de ésto, chequéa “AHA Programming”

Una nota… ¿Solo querés jugar con cosas? ¿Solo querés enviar cosas? Eso es totalmente genial. Solamente reconocé que no conocés los alcances de React y eso puede jugarte en contra en el futuro. Si el futuro no te importa tanto, ¡entonces no te preocupes!

Empezando con Javascript + JS Moderno

Una de las cosas que amo de React es “cuán Javascript es”. Si podés construir una simple aplicación con Javascript regular y las APIs del DOM, entonces vas a entender mucho mejor los beneficios de React. También vas a ser mucho más efectivo usando React, porque honestamente, el 90% de ser efectivo con React es entender buen JavaScript. Para ésto, te sugiero leer mi publicación “Javascript to know for React”. También echa un vistazo a javascript30.com (gratuito) y beginnerjavascript.com (pago), ambos de Wes Bos.

Además, conocer las características del JavaScript Moderno irá muy lejos. Debido a que JSX necesita un compilador, la mayoría de los desarrolladores/as React dan por sentadas las características/compiladores del Javascript moderno. Asi que la mayoría de los tutoriales van a asumir que tu tienes una comprensión básica de las características modernas de Javascript. Para eso, les sugiero mi Workshop “ES6 and Beyond” (free) que es una grabación de un taller que di en PayPal.

Luego, vamos a aprender React

Demasiado material “para principiantes” de React empieza con JSX y un montón de herramientas. React en sí mismo es sorprendentemente simple (y la documentación es muy buena, sobre todo la Beta). Lo que amo de React es su simplicidad. Tristemente, todo alrededor de él puede volverse complicado y puede ser difícil de saber donde están los límites entre React y las herramientas/librerías que se usan con él. Es por ésto que creé “The Beginner’s Guide to React” totalmente gratis en Egghead.io. Empieza con todo en el archivo index.html, lo que creo que es importante. No necesitas ninguna herramienta para usar React. He construido proyectos reales con ésta aproximación para una rápida iteración y despliegue. Francamente, no puedo pensar en una forma más rápida de construir ese tipo de aplicaciones simples, y ésto te permite evitar una gran cantidad de innecesaria complejidad y llegar a construir y entregar aplicaciones rápidamente. Podés aprender más sobre ésta aproximación en mi publicación “Super Simple Start to React”.

La última lección de mi curso gratuito de egghead te muestra cómo usar CodeSandbox.io para crear tu aplicación completamente en el navegador y descargarla a tu computadora a una aplicación create-react-app.

¡No necesitas nada instalado para llegar muy lejos! Y una vez que lo hagas, puedes avanzar mucho sin tener que configurar ninguna herramienta. Conozco varias empresas que desarrollan su aplicación con create-react-app.

Además, tengo una gran cantidad de contenido relacionado con React en mi blog 😅

Si buscas el camino rápido para aprender React, no busques más allá de EpicReact.Dev. Te enseñará todo lo que hace mi Guía para principiantes de React y MUCHO más. EpicReact puede ser tu compañero desde el inicio de tu viaje con React hasta convertirte en un jefe completo en esto. Y lo hace de manera tan efectiva gracias a su enfoque basado en ejercicios. Pasarás MUCHO más tiempo con tus dedos en el teclado aplicando lo que estás aprendiendo que lo que cualquier curso en línea típico te dará. No te pierdas EpicReact.Dev.

Dependencias y npm

Una vez que hayas decidido que no quieres escribir tu propia versión de cada componente que uses, puedes empezar a investigar las dependencias. Hay un MONTON de componentes por ahí y aquí es donde realmente debes comenzar a hacer preguntas como “cuál es el costo” y “cuál es el beneficio”. Trata de no agregar una dependencia hasta después de “sentir el dolor” que se supone que resuelve. Te hará más efectivo usando esa dependencia.

Te sugiero que leas la documentación de npm en una tarde. En serio, hazlo. Hay información realmente valiosa allí.

Además, cuando comiences a usar dependencias, querrás aprender a importarlas. Tengo una charla llamada “More than you wanto to know about ES6 Modules” que probablemente encuentres llena de información útil sobre la sintaxis de los módulos ES.

Remix

Es hora de ser serios sobre la construcción de una aplicación en el mundo real. No importa lo que planees construir con React en la web, estarás bien servido si usas Remix como tu framework de elección. Me ha permitido construir éste sitio web con un excelente rendimiento y manteniendo un código fantástico que amo trabajar.

Para aprender Remix, recomiendo la documentación oficial. También tengo algún contenido de Remix en mi blog que podría ser útil para ti.

Gestión de estado

La mayor parte de la gestión típica del estado será administrada por Remix, pero para el estado de la interfaz de usuario (estado que no se persiste en un backend), tendras que comprender cómo gestionar el estado dentro de React.

Cuando aprendiste React, aprendiste sobre la API useState. Probablemente también aprendiste sobre Lifting State Up. En realidad, esto puede llevarte muy lejos con React y te animo a seguir haciéndolo mientras puedas. Eventualmente, es posible que comiences a tener algún problema con “el prop-drilling”. Lo sabrás cuando lo sientas. Cuando esto suceda, te sugiero que leas mi publicación “Application State Management”.

React es una biblioteca de gestión del estado de la aplicación y no necesita Redux.

Estilo de componentes

Honestamente, no puedo dejar de recomendar Tailwind. Una vez que tu aplicación tenga más de unas pocas cientos de líneas de CSS, encontrará que Tailwind puede simplificar realmente las cosas conceptualmente para ti. Es “un framework de CSS con prioridad a las utilidades para construir rápidamente diseños personalizados”.

Eso dicho, Remix tiene un mecanismo fantástico para cargar (y descargar!!) CSS en una base por ruta, por lo que puede ser capaz de manejar solo escribir CSS regular por un tiempo antes de necesitar algo como Tailwind.

Y además…

Desde aquí te sugiero que te sumerjas más profundamente en React. Tengo mi curso de Patrones avanzados de componentes de React en egghead.io que puede darte mucha información realmente buena (pero puede obtener una versión más actualizada de este contenido en EpicReact.dev de todos modos, por lo que te sugiero que lo tomes).

Conclusión

Espero que esto te dé (y a sus amigos) un camino para cómo aprender React y dónde comenzar cuando se construyen aplicaciones de React. Agregar abstracciones a tu aplicación demasiado temprano las hace menos flexibles, por lo que generalmente seguiría este patrón al construir aplicaciones. ¡Buena suerte!

Bienvenida

Christian Caracach — Mon, 21 Aug 2023 00:31:36 +0000

Mi nombre es Christian. Tengo 32 años y soy de Unquillo, Córdoba (Argentina). Hace un tiempo que soy Desarrollador Frontend para una compañía que se llama VelaONE.
Siempre quise tener un blog, pero me di cuenta que mi habilidades son nulas en la escritura de contenido. Simplemente no me sale. Pero hace poco me di cuenta que quizás no puedo escribir, pero puedo traducir artículos que están en inglés.
Ésto lo descubrí un día en el que estaba leyendo el blog de Kent C. Dodds y me encontré con ésta leyenda .

Dije “eu, en serio nadie le traduce los blogposts a Kent C. Dodds?” — “Lo voy a hacer yo”.
Cuento con la experiencia de haber contribuido con la traducción de unos cuantos ejercicios de FreeCodeCamp (de las primeras dos certificaciones). Asi que por qué no…
En éste blog voy a traducir artículos (del inglés al español-argentino) que a mí me interesen sobre programación. Seguro va a estar más enfocado a React y todo su ecosistema, pero no descarto traducir artículos relacionados a CSS, a Javascript, al mundo IT en general.
Pero antes de terminar tengo que sincerarme y hacer dos avisos MUY importantes:
1 — No soy un traductor, no soy profesor de inglés, no tengo ninguna titulación en eso. Las traducciones no van a ser perfectas, si querés corregirme algun error, bienvenido sea, mandame un mail buena onda a christiancaracach@gmail.com
2 — Está bueno leer artículos traducidos al español (español argentino), pero no te olvides que en éste rubro, mientras más inglés sepas, mejor, así que también intentá leer los originales asi vas practicando.
Muchas gracias por su atención, que lo disfruten.