No: Devuelve nuevas matrices u nuevos objetos de mapStateToProps. Si se va a devolver un objeto, asegúrese de que no se modifique más adelante. Esto podría provocar que todo el componente y el subárbol se vuelvan a representar cuando este objeto cambie incluso lo más mínimo. 

Hacer: mapstateToProps solo debe devolver primitivas y matrices que provienen directamente del estado (no cree una nueva matriz a partir de mapStateToProps; si es necesario, cree un selector que almacene en caché la matriz resultante del cálculo de los argumentos). Las matrices que se repetirán más adelante deben contener la identificación de la cadena del elemento que se va a representar. El elemento de la lista es el responsable de encontrar la información sobre el estado global utilizando la identificación pasada desde los accesorios.

Hacer: Al crear su propio gancho personalizado, asegúrese de que la matriz que se devolverá también esté memorizada. No se recomienda la optimización prematura, pero ¿por qué no crear algo de la manera más óptima posible? No requiere una gran cantidad de esfuerzo y promueve el aprendizaje de otros ingenieros que trabajan en el código. ¡Mejora las habilidades del equipo!

Hacer: Al construir un objeto grande, ordena las claves en orden alfabético. Es probable que los objetos crezcan de tamaño y buscar una propiedad puede llevar mucho tiempo. Especialmente en la tienda, asegúrese de que los reductores estén ordenados alfabéticamente.

No: cree reductores que sean específicos de la página/pantalla que está creando. Piense en cómo podría escalarse a otras páginas/pantallas. Consulta con el equipo para ver posibles usos futuros de las páginas/pantallas que estás creando.

Hacer: Asegúrese de envolver las comunicaciones con API externas con una API personalizada. En el futuro, si es necesario reemplazar el servicio, se podrá realizar en esta API personalizada. Piense en Bugsnag, por ejemplo. Envuelve a ese bebé en una API personalizada en caso de que quieras usar Sentry en el futuro.

Hacer: En la misma nota. Estandarice la forma en que se manejan los errores en el backend pero también en el frontend. Cada acción en la aplicación debe incluirse en un bloque try/catch y el bloque catch envía informes a la herramienta de informe de errores. Su aplicación también debe envolver toda la aplicación con un límite de error. Creo que existe una manera adecuada de establecer el patrón correcto. Un patrón que es capaz de detectar todos los errores y reportar información significativa.

Hacer: use una herramienta que refuerce la calidad del código como Sonar, esto ahorrará mucho tiempo durante la revisión del código solo porque alguien decidió usar if ... else en lugar de if ... return . Pequeños pequeños detalles que hacen que un desarrollador sea menos creativo y se limite a seguir lo que dicen los estándares de calidad del código. Una base de código que sigue incluso estos detalles al detalle es fácil de codificar desde el primer día.

Conclusión

Estas son todas las opiniones que tengo en este momento. Al tener una base de código que aplica patrones, las personas pueden saltar y tomar un fragmento de código de algún otro lugar de la base de código, pegarlo, cambiar un poco la redacción y listo, tiene una característica que cumple con los estándares de producción en todas las formas posibles. Hay opiniones, pero realmente existe una forma más eficaz de hacer las cosas, al menos al momento de escribir este artículo. Es posible que surjan otros enfoques, pero la forma más eficaz de escribir el código en el momento de escribirlo es la única forma de escribir el código. Es más fácil decirlo que hacerlo hasta que te encuentras con el monstruo de los plazos.