Mejores prácticas de React para mejores aplicaciones ReactJS

Si está investigando la mejor manera de estructurar la estructura de carpetas de su aplicación React, sin duda se habrá encontrado con una amplia variedad de opiniones. Si bien este tema puede ser un poco subjetivo, existen algunas pautas que es mejor seguir. Entonces, ya sea que sea completamente nuevo en el desarrollo de React o que ya tenga experiencia con una opinión diferente, aquí hay algo para todos.

#1 Mejores prácticas para la estructura de carpetas de React

Agrupar carpetas por recursos

Si conoce las funciones que se incluirán en su aplicación ReactJS, puede crear fácilmente una estructura de carpetas basada en estas funciones clave. Al hacer esto, podrá mantener una estructura de directorios bien organizada para su aplicación y sabrá exactamente qué código va a dónde. Esto también hace que sea mucho más fácil depurar y colaborar.

Evite el anidamiento profundo

Al crear su estructura de carpetas, no querrá terminar con muchas carpetas anidadas. Si está haciendo esto al principio, es posible que deba repensar la jerarquía de sus carpetas y desglosar las cosas de manera más granular. Uno de los mayores problemas con el anidamiento profundo es que resulta difícil escribir importaciones relativas entre estas carpetas profundamente anidadas o actualizarlas cuando se mueven archivos.

Pensar demasiado es tu enemigo

Al iniciar el proceso de creación de la estructura de carpetas de su proyecto, no lo piense demasiado. Si tiene problemas para comenzar (porque su cerebro está pensando en círculos), simplemente descargue todos los archivos de inicio en la raíz del documento. A medida que el proyecto avance, verá exactamente cómo debería verse la estructura de carpetas. Una vez que esté claro, cree las carpetas y mueva los archivos a sus nuevos hogares. Incluso puedes comenzar con una carpeta src dentro de la carpeta base del proyecto y luego mover archivos fuera de esa carpeta a medida que las cosas se vuelvan obvias. Sólo asegúrese de no dejar su proyecto en esta estructura de carpetas únicas, ya que las cosas pueden volverse muy confusas a medida que el proyecto crece.

Simplemente podría comenzar con una única carpeta base (src) y dos subcarpetas (App y List) para albergar los componentes de su aplicación, que podrían verse así:

 -src/

   ---Aplicación/

      ----- index.js

      -----App.js

      -----Aplicación.test.js
 
-----Aplicación.style.css

 ---Lista/

 ----- index.js

 ----- Lista.js

 ----- Lista.test.js

 ----- Lista.estilo.css

Componentes y utilidades separados

También puedes estructurar tus carpetas separando los componentes de los ganchos. Este tipo de estructura de carpetas podría verse así:

 -src/

   --- componentes/

      -----Aplicación/

         ------- index.js

         ------- componente.js

         ------- prueba.js

         ------- estilo.css

      -----Lista/

         ------- index.js

         ------- componente.js

         ------- prueba.js

         ------- estilo.css

   --- ganchos/

      -----useClickOutside/

      ------- index.js

      ------- gancho.js

      ------- prueba.js

   ----- usarScrollDetect/

      ------- index.js

      ------- gancho.js

      ------- prueba.js

#2 Mejores prácticas de la biblioteca de pruebas de React

Pruebe el comportamiento, no la implementación

Hay una gran diferencia entre comportamiento e implementación. La diferencia es simple:

• Al evaluar el comportamiento, no le importa cómo llega a la respuesta, sólo si la respuesta es correcta en un conjunto determinado de circunstancias.
• Al probar la implementación, no le importa cuál sea la respuesta, simplemente haga algo específico mientras lo resuelve.

Es más probable que las pruebas de comportamiento lleguen a una conclusión viable y repetible, por lo que realizar pruebas de esta manera es su mejor opción.

Utilice métodos de representación personalizados para modelos de dependencia

Al utilizar un método de representación personalizado para simular dependencias, puede evitar tener que realizar la misma configuración cada vez que ejecuta una prueba. A medida que su proyecto crezca, seguramente no querrá realizar la misma configuración para cada prueba. Con métodos de renderizado personalizados, sus pruebas de simulación también son más repetibles y fáciles de mantener.

Funcionalidad de prueba, no implementación

Si se concentra en probar los detalles de la implementación, lo que está haciendo es probar cómo está escrito su código, no qué hace. Al seguir esta ruta, si cambia su código, sus pruebas fallarán, incluso si la funcionalidad del código no ha cambiado. Si, en cambio, prueba la funcionalidad, esas pruebas siguen siendo viables incluso si cambia la implementación de su código.

Escriba pruebas que no se rompan cuando cambie la interfaz de usuario

Su interfaz de usuario cambiará. Esto es inevitable. Al crear sus pruebas, debe tener esto en cuenta y escribirlas de tal manera que no se rompan si cambia la interfaz de usuario. Asegúrese de crear pruebas que se centren en el comportamiento de un componente en lugar de en la implementación. Por ejemplo, en lugar de probar si un menú usa la clase CSS correcta, debe probar para asegurarse de que hacer clic en el menú proporcione los resultados esperados.

No pruebes lo que React ya prueba

La biblioteca React ya está muy bien probada. Cuando utilice componentes de la biblioteca, no necesitará probarlos. En su lugar, centre sus pruebas en los componentes y el código que escribe. Evite tales despidos ya que sólo hacen perder tiempo.

Utilice ayudantes de simulación de eventos

React incluye varios asistentes de simulación, como cambiar, hacer clic y presionar teclas, que simulan eventos sin desencadenarlos realmente. Asegúrese de utilizar estos ayudantes, en lugar de fireEvent, ya que esto en realidad envía un evento al DOM. Dado que el nodo DOM no puede manejar ciertos tipos de eventos, esto puede causar problemas.

Utilice siempre Act para probar eventos asincrónicos

En la misma línea, siempre debes usar act para probar eventos asincrónicos. Con eventos asincrónicos, la biblioteca de pruebas de React esperará a que se completen las tareas antes de ejecutar cualquier aserción. El problema es que sólo funciona si las tareas asincrónicas se inician con un controlador de eventos. Para evitar este problema, envuelva su tarea asíncrona en una llamada de acto para que la biblioteca de pruebas de React permanezca hasta que se completen todas las tareas asíncronas antes de ejecutar las aserciones.

Afirmar solo una cosa por prueba

Esto es fundamental. Si afirma varias cosas por prueba y una de ellas falla, la prueba fallará y no sabrá qué afirmación está causando el problema. En su lugar, centre sus pruebas en una sola afirmación para que, si la prueba falla, sepa exactamente qué afirmación es problemática.

Mantenga sus pruebas simples y enfocadas

Otro aspecto importante de las pruebas es mantenerlo simple. Cuando crea pruebas demasiado complejas, depurar problemas se vuelve más difícil. Esto es especialmente cierto a medida que su proyecto se vuelve más complejo.

#3: Mejores prácticas de seguridad de React

Utilice protección estándar de secuencias de comandos entre sitios con enlace de datos

Aunque React es bastante seguro, aún puede ser vulnerable a cosas como secuencias de comandos entre sitios (XSS). Por ejemplo, siempre debe utilizar claves para el enlace de datos estándar. Esto garantiza que React escapará automáticamente de los valores para protegerse contra ataques XSS. Aquí hay un ejemplo.

En vez de:

 <formulario acción={datos}>

Utilizar esta:

 <div>{fecha}</div>

Evite la inyección de scripts basados ​​en URL

Al utilizar el protocolo javascript:, las URL pueden contener contenido dinámico que puede conducir a la inyección de secuencias de comandos basadas en URL. Para evitar esto, utilice una función de análisis de URL nativa y luego combine la propiedad del protocolo analizado con una lista blanca.

Utilice una biblioteca de saneamiento

Con ReactJS, HTML se puede insertar directamente en nodos DOM representados con peligrosaSetInnerHTML, lo que permite a los desarrolladores insertar directamente contenido HTML dentro de un elemento HTML en una aplicación React. Al insertar contenido de esta manera, siempre se debe desinfectar utilizando una biblioteca de desinfección como DOMPurify. Utilice esto en cualquier valor antes de colocarlo en la propiedad peligrosamenteSetInnerHTML. Un ejemplo de esto es así:

 importar purificar de "dompurify";

 <div peligrosamenteSetInnerHTML= {{ __html:purify.sanitize(data) }} />

Verifique las vulnerabilidades de dependencia conocidas

Si está utilizando componentes de terceros, verifíquelos cuidadosamente para detectar vulnerabilidades que puedan contener. Debido a que estos componentes están prediseñados por otro programador (o equipo), no desea confiar simplemente en que estos componentes se prueben para detectar problemas. Si no está seguro de la seguridad de un componente, pruébelo antes de implementarlo.

Evite los ataques de inyección JSON

Los datos JSON se envían comúnmente con páginas renderizadas del lado del servidor en React. Al hacer esto, siempre escape < caracteres con cualquier valor benigno. Al hacer esto, evitará ataques de inyección.

Aquí hay un ejemplo para ilustrar esta práctica:

 ventana.__PRELOADED_STATE__ = ${JSON.stringify(preloadedState).replace( /</g, '\\u003c')}

Utilice versiones seguras de React

Asegúrese siempre de estar utilizando la última versión de React. De lo contrario, corre el riesgo de utilizar una versión que contenga vulnerabilidades, algunas de las cuales pueden ser críticas. Esto se aplica tanto a reaccionar como a reaccionar.

Usa un linter

Existen herramientas, llamadas linters, que pueden ayudar a detectar cualquier problema de seguridad en su código base. Uno de esos linter es ESLint React Security Configuration Tool , que es de código abierto y está disponible de forma gratuita. Linters no solo debe usarse en su código personalizado, sino también en el código de la biblioteca. Siempre es mejor prevenir que lamentar.

#4 Mejores prácticas de autenticación de React

usar una biblioteca

Cuando necesite confiar en la autenticación para su aplicación, siempre es mejor confiar en una biblioteca. Recuerde que la autenticación es un asunto serio y puede generar muchos riesgos. En lugar de escribir código personalizado, que puede estar plagado de problemas de seguridad, recurra a una biblioteca prediseñadas para el recurso. Encontrará muchas bibliotecas de autenticación de React disponibles que pueden cumplir muchas funciones diferentes. Encuentra uno que se adapte a tus necesidades y úsalo.

No almacene datos confidenciales en el almacenamiento local

En algún momento tendrás que almacenar datos confidenciales, algunos de los cuales pueden ser datos de usuarios/clientes. Cuando almacena datos en un almacenamiento local (del lado del cliente), significa que cualquier persona que tenga acceso al dispositivo (o incluso a aplicaciones de terceros) puede acceder a esos datos, lo que puede generar problemas de seguridad. En lugar de almacenar estos datos en un almacenamiento local, utilice una opción más segura, como el almacenamiento de sesiones. Mejor aún, no almacene información confidencial en el dispositivo local… punto.

Asegure sus puntos finales API

Un punto de seguridad que algunos pasan por alto son los puntos finales API. El problema con los endpoints es que si un atacante logra acceder a uno (o más), tiene acceso a todo, incluidos los datos de los clientes. Un método para proteger los puntos finales de API es con JSON Web Tokens (JWT), que son un método estándar de la industria para transmitir información de forma segura. Antes de transmitir la información, el token debe verificarse en su servidor.

Si los JWT no son una opción, al menos debería utilizar HTTPS para el cifrado de datos. De esta manera, si un atacante obtiene acceso a una API, al menos los datos estarán cifrados y no podrán leerse fácilmente. El uso de HTTPS también tiene el beneficio adicional de proteger contra ataques de intermediario, que es otra forma más para que un atacante obtenga acceso a sus datos.

Cifre contraseñas y otra información confidencial

Hablando de cifrado, nunca deje contraseñas ni otra información confidencial sin cifrar. Hacerlo deja su aplicación o servicio abierto a ataques. Peor aún, si su aplicación o servicio es utilizado por consumidores o clientes y almacenan contraseñas y otra información en la aplicación, si esa información no está cifrada, los piratas informáticos pueden acceder a esos datos y leerlos. Nunca se deben dejar abiertos los datos del cliente/consumidor de esta manera.

Implementar limitación de velocidad en los intentos de inicio de sesión

Si no utiliza la limitación de velocidad para los intentos de inicio de sesión, deja su aplicación o servicio expuesto a ataques de fuerza bruta. Con esto en juego, es sólo cuestión de tiempo antes de que un hacker consiga irrumpir en su aplicación/servicio y robar los datos que contiene. Debe limitar los intentos de inicio de sesión a, por ejemplo, cinco intentos fallidos en un período de tiempo determinado. Si se supera este límite, la cuenta deberá bloquearse durante un período de tiempo determinado. Al hacer esto, su sistema tendrá la oportunidad de detectar e informar estos intentos fallidos. Sin limitación de velocidad, los atacantes pueden seguir pirateando inicios de sesión hasta que lo hagan bien y obtengan acceso a su aplicación o servicio.

Utilice 2FA o MFA para mayor seguridad

Muchos usuarios dudan en utilizar la autenticación de dos factores (2FA) o la autenticación de múltiples factores (MFA) para iniciar sesión. Una vez que finalmente entienden por qué se usa esto (y que no es el inconveniente que asumieron), los usuarios aceptan estas capas adicionales de seguridad. En lugar de hacer que 2FA o MFA sean opcionales, considere hacerlo obligatorio. Si bien 2FA y MFA no son perfectos, ciertamente hacen que sea más difícil para los posibles atacantes obtener acceso a su aplicación o servicio. Cualquier seguridad adicional que pueda agregar a su aplicación, servicio o sitio web debe considerarse obligatoria.

No utilice el correo electrónico como nombre de usuario

Hablando de seguridad de la cuenta, considere prohibir las direcciones de correo electrónico como nombres de usuario. ¿Por qué? Las direcciones de correo electrónico para nombres de usuario son una práctica muy común, lo que significa que los piratas informáticos tienen menos problemas para adivinar los criterios de inicio de sesión. En lugar de utilizar direcciones de correo electrónico para los nombres de usuario, considere obligar a los usuarios a crear nombres de usuario únicos, lo que hace que sea considerablemente más difícil para un pirata informático romper la autenticación, lo que hace que su aplicación sea considerablemente más segura.

Utilice autenticación sin contraseña

Uno de los métodos de autenticación más seguros es el sin contraseña. En lugar de utilizar una contraseña típica para iniciar sesión, los usuarios reciben un código único que se envía a su número de teléfono y luego usan el código para iniciar sesión. Aún más seguro es utilizar un código de una aplicación de autenticación, como Authy o Google Authenticator. Dado que estos códigos son de un solo uso, un pirata informático no tiene forma de adivinar la contraseña, ya que no hay contraseña que adivinar. El único inconveniente de la autenticación sin contraseña es cuando los códigos se envían, por SMS, a un teléfono. Estos códigos pueden ser interceptados por piratas informáticos, lo que facilitaría considerablemente el acceso a una cuenta. Por supuesto, si el usuario trabaja con un nombre de usuario único (y no una dirección de correo electrónico), incluso si el hacker intercepta el código, tendrá que conocer el nombre de usuario asociado con la cuenta para obtener acceso.

Desconectar usuarios inactivos

Una cosa acerca de las aplicaciones móviles y web es que los usuarios trabajarán con ellas por un tiempo y se aburrirán de la aplicación o ya no encontrarán la necesidad de usarla. En el caso de una aplicación móvil, estas aplicaciones olvidadas tienden a permanecer instaladas y las cuentas abiertas. Esto podría ser un problema de seguridad. Para solucionar esto, considere incorporar un cierre de sesión automático después de un cierto período de tiempo en su aplicación/servicio. Cuando cierras automáticamente la sesión de estos usuarios en la aplicación, los terceros no pueden desbloquear el teléfono y abrir la aplicación sin autenticarse primero. Sí, puede ser un inconveniente menor para los usuarios que no abren la aplicación con regularidad, pero esa comodidad no es nada comparada con una cuenta pirateada. Si la cuenta de un usuario es pirateada, no hay forma de saber si el mal actor infractor no podrá obtener acceso a otras cuentas, un punto final API o su servidor de alojamiento.

Mejores prácticas de ReactJS: conclusión

ReactJS se utiliza ampliamente en todo el mundo para crear interfaces interactivas para aplicaciones web y móviles. Dada la omnipresencia de este tipo de aplicaciones, corresponde a los desarrolladores seguir siempre las mejores prácticas para evitar que los piratas informáticos obtengan acceso a datos confidenciales, lo que puede causar más problemas de los que imagina.

Con un poco de precaución desde el principio, se puede evitar tal catástrofe. El resultado final es que sus clientes confiarán en su aplicación y en su empresa. Este nivel de confianza no se puede comprar ni vender, por lo que debe considerarse un activo invaluable.

Si te gustó este artículo sobre React, consulta estos temas;

• Reaccionar bibliotecas de componentes de UI
• Los 6 mejores IDE y editores de React
• ¿Por qué React es tan popular?
• Lo que necesitas saber sobre reaccionar
• Representación del lado del servidor en React
• Reaccionar WebSockets: Tutorial