"By Feature" Approach, Scaffolding React Native

Existen muchas maneras de escribir nuestros proyectos de React Native, la forma en que organices tu proyecto tiene un gran impacto en la calidad del mismo, hoy veremos "By Feature", en otras palabras "Package by Feature approach". Existe también otra forma de llamarlo "Feature-Driven Development (FDD)".

‍

Package by Feature approach

Habiendo tantas formas de estructura nuestro código nos encontramos en el reto de cómo saber que estamos realmente aplicando una tecnica o no? bueno en el caso de React Native Package by Feature, lo podemos resolver con una simple pregunta.

"Test de eliminación" , si la eliminación de un feature es una única operación, entonces es una implementación limpia realmente modular o by feature. Por ejemplo, si eliminar un feature involucra eliminar tan solo un directorio, significa que es modular, pero si en cambio tenemos que ir a muchos lugares para eliminar severos archivos, entonces no es realmente modular.

Pero primero hablemos de un par de conceptos, conceptos que vamos a ver muy seguido con nuestros clientes.

‍

Loose coupling

En palabras simples, el Loose coupling significa que son en su mayoría independientes. Si el único conocimiento que la clase A tiene sobre la clase B, es lo que la clase B ha expuesto a través de su interfaz, entonces se dice que la clase A y la clase B son Loose coupling, es lo opuesto al siguiente término.

‍

Tightly coupled

En general, el Tightly coupled significa que las dos clases a menudo cambian juntas. En otras palabras, si A sabe más de lo que debería sobre la forma en que se implementó B, entonces A y B están Tightly coupled.

‍

Encapsulation

La encapsulación es la agrupación de datos y los métodos que actúan sobre esos datos de manera que el acceso a esos datos está restringido desde fuera del paquete, o como lo describe Alan Kay, "retención local y protección y ocultación del proceso de estado". En OOP, eso significa que un objeto almacena su estado de forma privada, y solo los métodos del objeto tienen acceso para cambiarlo.

‍

Características de los "Feature approach"

• El código es mas sencillo de refactorización si se diera la necesidad puesto que internamente sus métodos privados puede ser modificados mientras que los públicos podrian mantener su firma y output.
• Tratar cada feature como una implementación isolada, viéndolos casi como un mundo separado.
• En general, los JS Imports no deben de mezclarse entre features, la comunicacion debe ser limitada por los métodos públicos. (No romper encapsulation)
• Posibilidad de Feature-flag, termino que se aplica para habilitar/deshabilitar funcionalidades completas con mucha facilidad.

‍

Ejemplo de un "Feature approach"

Usemos de ejemplo nuestro feature de login, este feature sera exportado manteniendo los principios mencionado arriba.

‍

Retos interesantes del "Feature approach"

¿Como se comparte el código?

Una de las formas mas sencillas seria creando un folder shared el cual podrá utilizar para compartir utils y helpers por ejemplo. Por ejemplo servicios como Api, Data Storage, helpers de seguridad, pueden ir en ese directorio.

‍

En conclusion

En el articulo, yo te mostre como podemos pensar al estructurar proyectos y archivos de React native, espero que hayas encontrado realmente útil y te guste suscribirte para más artículos, eventos y oportunidades laborales!

‍

¿Qué opinas?

¡Comparte tu opinión con nosotros y tus experiencias, ¿que te parecio?!

‍