Patrones de otros lenguajes y marcos para mejorar sus proyectos frontend

Llevo doce años programando y he trabajado con muchos lenguajes. Estos incluyen C , C++ , Java , Python , C# y, finalmente, JavaScript . Cada lenguaje o framework tiene sus propias reglas. Por ejemplo, Rust usa mayúsculas y minúsculas para los nombres de las funciones.

Sin embargo, hay ciertas reglas, herramientas y patrones que he aprendido a apreciar. Los incorporo en mis aplicaciones frontend. Estas reglas simplemente resuenan más conmigo y hacen que la codificación sea un proceso más fluido. Aquí hay algunos que prefiero especialmente:

Programación funcional

Mi primer consejo proviene de C, el primer idioma que aprendí. ¿Recuerdas cuando solíamos escribir React con clases ? Solo de pensarlo me da escalofríos. Cuando React cambió a componentes funcionales, hizo que el código no solo fuera más fácil de leer sino también más fácil de probar.

También se alinea mejor con los principios de la Programación Funcional.

Este enfoque funciona muy bien con los marcos frontend porque a menudo se enfocan en crear piezas de código reutilizables. El uso de la programación funcional en el desarrollo de frontend siempre ha sido una estrategia útil para mí para comprender este concepto y también para crear nuevas funciones de frontend.

Seguir los principios de la programación funcional es imprescindible en todas mis aplicaciones frontend.

Si no está familiarizado con la programación funcional, le recomiendo que la explore más a fondo. Este punto no está al principio de esta lista sin razón. Los beneficios que puede aportar a su proceso de desarrollo son sustanciales.

Formateadores de código

Cuando comencé a programar, no presté mucha atención al formato del código. Supongo que todo comenzó en la universidad donde estaba aprendiendo C++ en mi genial IDE de CodeBlocks con un tema blanco.

Mirando hacia atrás en mi código anterior de 2016 en GitHub , puedo ver que solo usé espacios para formatear. No utilicé ninguna herramienta para encargarme automáticamente de esto.

Ahora me doy cuenta de que fue un error. Si puede automatizar algo en su proyecto, definitivamente debería hacerlo. Ahora, siempre configuro Prettier y ESLint al comienzo de cada proyecto. Si no quieres dedicar mucho tiempo a esto, puedes usar configuraciones prefabricadas como la de Airbnb .

Confía en mí, ¡no te arrepentirás!

¡Ah, y no se olvide de configurar en su IDE una acción de formato automático al guardar el archivo!

Acciones previas a la confirmación

Ahora que tiene formateadores increíbles, ¡automaticémoslos! No puedo recordar exactamente cuándo comencé a usar ganchos de confirmación previa, pero han sido de gran ayuda en mis proyectos. ¿Por qué formatear manualmente cuando se puede automatizar antes de cada confirmación? Herramientas como husky y lint-staged hacen posible esta automatización.

Kebab-case para nombres de archivo

Aunque Angular tiene muchos seguidores y críticos, me gusta centrarme en lo positivo. Angular suele ser la primera opción para grandes empresas y grandes aplicaciones. Creo que muchas de las decisiones tomadas en Angular estaban destinadas a mantener las cosas fáciles de mantener.

Es por eso que decidí usar kebab-case para todos mis proyectos frontend. Ofrece algunos beneficios, como:

• Simplicidad : no tengo que preocuparme por usar pascal-case, camel-case o snake-case (si lo prefiere). Con kebab-case, solo hay una opción.

• Coherencia : si está trabajando en un equipo, adoptar una sola convención de nomenclatura como kebab-case puede ayudar a garantizar que todos estén en sintonía y que el proyecto se mantenga organizado. No olvide que puede forzar el uso de kebab-case a través de la regla eslint usando el paquete unicornio :

 'unicorn/filename-case': [ 'error', { case: 'kebabCase', }, ],

• Compatibilidad multiplataforma : los diferentes sistemas operativos manejan los nombres de archivo de manera diferente. Por ejemplo, a Windows no le importan las mayúsculas, pero a Linux sí. Al usar kebab-case, que usa letras minúsculas y guiones, evito cualquier problema.

• Sin problemas de git : hay un problema al cambiar el nombre de un archivo de minúsculas a mayúsculas en git. Usando kebab-case, no tengo que preocuparme por eso.

Me gusta mantener las cosas simples. Si puedo hacer mi vida más fácil y obtener algunos beneficios de ello, estoy totalmente de acuerdo.

Uso de etiquetas para tipos de archivos

Otra cosa que tomé prestada de Angular es cómo nombran los archivos. Angular recomienda nombrar archivos de una manera que refleje su función y tipo. Encuentro que me facilita la navegación y la comprensión de la estructura de un proyecto. En Angular, el nombre del archivo generalmente tiene tres partes: el área de funciones, la función del archivo y el tipo de archivo.

Por ejemplo, heroes.component.ts muestra que el archivo es un componente para la característica heroes y es un archivo TypeScript. heroes.service.ts es un servicio para heroes .

No soy un gran fanático de services , pero uso una estructura similar para mis componentes React. Aquí hay un ejemplo:

 my-component ├── my-component.component.tsx ├── my-component.type.ts ├── my-component.style.css ├── my-component.spec.tsx └── my-component.story.mdx

También uso este patrón para mis ganchos y funciones. Este patrón también me enseña a colocar mis pruebas junto a los archivos relacionados con ellas.

Automatice la generación de código

El patrón que mencioné antes es muy útil, pero podemos mejorarlo aún más con la automatización. Angular CLI permite a los usuarios generar código automáticamente y yo siempre uso plop para hacer lo mismo. El sistema de plantillas de Plop es muy poderoso, pero lo más importante es que ahorra tiempo.

Con la automatización, no tengo que dedicar mucho tiempo a pensar en la estructura básica de un componente. Esta tarea se puede automatizar, lo que me permite concentrarme en lo que realmente quiero hacer.

Usando un 'Dominio'

No voy a explicar qué es un domain en detalle aquí. Si quieres saber más al respecto, te recomiendo leer este artículo . En este momento, estoy trabajando con un equipo de desarrolladores completos y descubrimos que tener una capa de dominio en nuestro proyecto frontend es realmente útil.

Es donde ponemos todos nuestros tipos y operaciones principales. Sirve como la 'fuente de la verdad' en nuestra aplicación.

Si desea ver cómo manejo los 'dominios' en mis aplicaciones, puede consultar este artículo . Paso allí mucho tiempo describiendo este tema.

Probar su arquitectura

En nuestro trabajo con Kotlin , una vez nos encontramos con un problema en el que la lógica se mezclaba en varias capas, como usar un tipo definido en el repositorio dentro de nuestro dominio. Esto es imposible desde el punto de vista de la arquitectura limpia, pero todo el mundo comete errores.

Fue entonces cuando descubrimos ArchUnit , una herramienta para realizar pruebas unitarias de nuestra arquitectura. Básicamente comprueba si nos estamos adhiriendo correctamente a nuestra arquitectura.

Si está manteniendo una cierta arquitectura, puede ser útil tener una herramienta para verificar si no se ha roto en algún momento. Una herramienta como dependency-cruiser puede ser invaluable en este sentido.

Y eso concluye mi lista esencial de patrones de otros lenguajes y marcos para mejorar sus proyectos frontend. ¡Espero que haya encontrado útil esta información y que al menos una de estas estrategias lo haya inspirado a implementarla en su propio trabajo!