@inlaze_techlead/inlaze-ui-react
1. Introducción
1.1 Propósito
Brindar un concepto claro de la librería de componentes de React que es de uso general para todos los proyectos desarrollados en la empresa con este framework, para que en su proceso de desarrollo y mantenimiento mantenga las mismas convenciones y calidad.
1.2 Alcance
Tiene la razón de ser, funcionamiento y prácticas para su desarrollo y mantenimiento:
Exponer problemas a resolver: por la librería.
Definir Técnicas: adoptadas para resolver los problemas.
Dejar en manifiesto las convenciones: a tener en cuenta durante el proceso de implementación y mantenimiento.
1.3 Definiciones, Acrónimos y Abreviaturas
Cliente: Es quien instala la librería y utiliza los elementos expuestos que se pueden importar.
Contenedor: Es la etiqueta que envuelve todo el JSX o TSX de un componente, la etiqueta padre en el retorno de un componente funcional.
Contenedor cerrado: Hay componentes que tienen que definir un contenedor y este no puede ser modificado por props, debido a que la semántica del HTML lo requiere, por ejemplo el componente button debe tener como contenedor esa etiqueta, no puede permitir al cliente usar otra, pues se presta para que el desarrollador cometa el error de usar la semántica equivocada. Pero el button si puede recibir uno o varios ReactNode que van al interior del contenedor preestablecido.
Contenedor abierto: Es una prop tipo ReactNode que contiene todo el HTML que renderiza el componente, incluyendo evidentemente la etiqueta contenedora,
Genéricos: Se emplea este término en el contexto de lo que es tipado en typescript https://www.typescriptlang.org/docs/handbook/2/generics.html#handbook-content
Componente del UI-kit: Son componentes estructurados con HTML y no requieren de la importación de otros componentes. Estos componentes se definen en el UI-KIT por UX/UI de acuerdo al proyecto, como partículas de diseño que componen una aplicación.
Componente compuesto: Es un componente que se estructura con HTML y la reutilización de otros componentes para evitar la duplicidad de código, puede ser un componente con un comportamiento complejo, una sección como un header o incluso una página.
Componente base: Son componentes del UI-kit o compuestos tipo headless, significa componentes funcionales no estilizados. En esta librería además un componente base separa la funcionalidad del HTML, para que el cliente pueda definir el HTML que necesite y aparte pueda acceder a las funciones para que las invoque en cualquier parte del HTML o por cualquier evento que necesite.
Variante: Es un componente que reutiliza el componente base para generar presentaciones del mismo en un aspecto en particular, por ejemplo, versiones en las que un botón tiene relleno o no, si un radio es redondeado o no, un componente de texto sea de titulos o de párrafos.
Template: El propósito de hacer un esfuerzo en desacoplar las estructura HTML , los estilos y la funcionalidad en los componentes base es para que tengan la flexibilidad de ser reutilizados en los distintos proyectos y productos que pueda llegar a tener la organización. De forma que un template es un set de componentes que reutilizan y personalizan los componentes base con el sistema de diseño de un proyecto o producto en particular.
1.3 Referencias
Qué es un UI headless component: https://tailwindcss.com/blog/headless-ui-unstyled-accessible-ui-components.
Nx como constructor herramienta usada para construir la libreria: https://nx.dev/getting-started/intro
Comandos de NX para agregar componentes, historias de storybook, tests etc: https://nx.dev/nx-api/react
Convenciones para el equipo de desarrollo en cuanto a git, buenas prácticas en general, para Typescript, Next js y React: https://app.gitbook.com/o/GgVHVNkuRxgzk5EqCSHH/s/jRGD70dBf9UEyeTM7a1m/
Css modules como manera de estilizar en la libreria: https://create-react-app.dev/docs/adding-a-css-modules-stylesheet/
BEM como sistema de nombramiento de clases css: https://getbem.com/introduction/
2. Descripción general de la librería
2.1 Estructura
La librería esta creada como un proyecto de un workspace de NX, NX crea una carpeta con el nombre del proyecto en la raíz del repositorio con toda la configuración básica para lo que se necesite, en el repositorio lo concerniente a la librería se encuentra dentro de la carpeta libs, que en su interior se encuentra las carpetas definidas por NX
/project-root
│
├── /Libs
├──── /src
├────── /lib
│ ├── /common
│ ├── /ui-kit
│ ├── /compound-components
│ ├── /models
│ ├── /utils
│ ├── /core
│ ├── /models
│ ├── /utils
│ ├── /templates / product-name
│ ├── /ui-kit
│ ├── /compound-components
│ ├── /models
│ ├── /utils
Carpeta common: Contiene componentes, modelos y utilidades usados dentro de los templates.
Carpeta core: Contiene archivos de configuracion transversales a toda la librería y aquellos modelos y utilidades que sean de insumo para common.
Carpeta templates: contiene cada una de las carpetas que puedan existir por proyecto o producto de la empresa y expone solo aquellos recursos que se necesite para un conjunto de componentes, modelos y utilidades personalizadas.
2.2 Problemas que resuelve
Desde una misma librería se puede tener acceso a los componentes, modelos y utilidades que requiere el equipo de desarrollo frontend para su proyecto en particular, en cualquier repositorio que use React,
Se puede importar componentes, modelos y utilidades comunes a todos o varios de los proyectos que usen React.
Solo se necesita de la instalación de una sola dependencia para acceder a los elementos básicos que requiere un proyecto, y no tener que buscar entre múltiples dependencias cual es el que sea necesaria.
Minimizar la dependencia por otras librerías que puedan dejarse de mantener o se deprequen.
Establecer una librería de uso común a todos los proyectos permite controlar que los distintos proyectos no tengan configuraciones variadas sino convencionales y predecibles.
Con el fin de asegurar la escabilidad y mantenibilidad de los componentes reutilizables el componente base se reutiliza en destinos templates, pues esto permite que el desarrollo y mantenimiento de las funcionalidades del componente se haga solo un único componente base, y no en el mismo tipo de componente por cada uno de los proyectos.
2.3 Técnicas para solucionar los problemas descritos
En la siguiente página se plantean técnicas para solucionar programáticamente parte de los problemas anteriormente descritos.
Last updated