Adc-frontgenerales NPM

ReadmeADC

ADC - Generales :bust_in_silhouette:

Este proyecto es el encargado de gestionar los componentes comunes que se usan en todos los proyectos. Es exclusivo del equipo de desarrollo de ADC del módulo ABR. Construido con React + Vite.

Publicación :rocket:

Este paquete se publica en NPM. Es importante tener los siguientes puntos en cuenta para despliegues:

El proyecto debe compilar correctamente antes de publicar
Todos los test deben funcionar
Se gestiona por medio de archivos en barril iniciando en index.ts
Las versiones de prueba se publican con el sufijo de -p, ejemplo: 0.0.1-p10
No se debe publicar ningún componente cuyos test no cobran minimo el 90% de su funcionalidad. Validar cobertura.

Librerías en uso :book:

Este proyecto tiene varias dependencias, unas de las más importantes son:

Estandares de desarrollo :eyes:

Para la correcta codificación en este proyecto es primordial tener el cuenta los siguientes estadares de desarrollo:

Generales

El nombre de las carpetas inicia en minúscula.
El nombre de los componentes empieza por Mayúscula.
Pasar React.Dispatch únicamente cuando se va a utilizar el valor anterior de lo contrario una función normal.
Siempre pasar a componentes hijos un handleState en lugar de un setState directo. Si se usa internamente utilizar con normalidad.
No dejar código en desuso
Preguntar el funcionamiento del desarrollo antes de codificar IMPORTANTE

Interfaces

El nombre empieza por mayúsculas
Tiene que terminar en “Props“ cuando sea la interfaz de entrada de un componente.
Para los types se debe agregar el sufijo “Type” al final
Son de extensión .ts
Las interfaces de tipo “Props“ deben estar en el mismo archivo que el componente.
Cuando un componente requiere más de una interfaz se aloja en la carpeta de “Interfaces” esquematizando las carpetas según la funcionalidad.
El nombre de las propiedades empieza por minúscula.
Se puede dejar un archivo para una interface que tenga nidos
Interfaces de entrada dejar el sufijo “Response”.

Componentes

Seguir principios SOLID
Componetizar flujos determinando niveles de responsabilidad
Si es un componente hijo dejar con el prefijo "_" ejemplo: "_CardService.tsx"
Debe iniciar por mayuscula.
No debe tener referencias que no se estén usando.

Estilos

Se debe crear un StyledComponent cuando sea un componente personalizado del modulo y se use en varias vistas. De lo contrario se debe manejar con las propiedades de este o con sx.
No se deben manejar valores fijos (px) a no ser un caso excepcional.
Utilizar la unidad de medida rem (spacing en el tema de MUI)

Test

Se debe hacer un archivo para todos los test de un flujo
Toda funcionalidad debe estar testeada.
Los nombre de los test y desc deben ser descriptivos
La data mockeada debe estar independiente en un archivo al mismo nivel del test.