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:

• React
• Vite
• MUI

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.

Pautas de calidad para desarrollos :exclamation:

Los siguientes puntos determinan si un desarrollo se finalizó correctamente y se puede realizar un pull request.

• Debe compilar el proyecto correctamente
• Todo debe estar testeado y los test tienen que funcionar en su totalidad.
• No deben haber referencias que no se usen.
• No pueden existir debuggers o console.log

Licencia

Todo el codigo expuesto en este repositorio pertenece a SincoSoft. Todos los derechos reservados.