Tremendo crack. Muchísimas gracias. Actualmente, cumplí un año como Desarrollador Web y creé todo el front-end de una aplicación con React, pero fue mi primera app en producción. Aplicaré Clean Architecture para mejorar el código y aumentar la escalabilidad. Muchísimas gracias. :D
Tremendo video te mandaste man, con una información muy valiosa, especialmente para los que comenzamos. Busqué bastante info sobre el orden, patrones de diseño, etc etc, y nunca quedaba satisfecho, pero lo positivo, es que no estaba tan mal como venía trabajando, pero con esto seguro pego un salto de calidad. Muchisimas gracias por el aporte.
@@GentlemanProgramming Hola profe, quería saber si no le molestaba que le nombre en un Readme.md que estoy escribiendo para una nueva práctica que estoy haciendo en React, dónde voy a tratar de utilizar esta arquitectura que nos compartió, y quería destacar que es con este video que la conocí. Y cuándo tenga un tiempito si puede darme su parecer con respecto a lo siguiente "Si tenemos un componente el cuál tiene varios estados, varias funciones, y su respectivo jsx, pero definido en un archivo .js, es conveniente para que sea más limpio crear un name.jsx con el jsx mismo, los states y las funciones pero que el cuerpo de dichas funciones sólo llamen a otras funciones que se encuentran en un name.js (el mismo nombre que el jsx) con toda la lógica para manejar el estado y que estas funciones reciban como argumento ciertas variables y estados (state y setStates), asi lograr componentes un poco más limpios? O hacer todo en un .js derecho, o bien, usar una carpeta helper o algo similar (que es lo que hacía pero no se si sea buena práctica) ... espero haberme hecho entender. Agradecería mucho si podría orientarme."; Muchas gracias, y que tenga una muy buenas tardes.
@@cuaticito primero que sería un honor ! Y la idea es la siguiente, digamos que tienes un componente que abre un diálogo, este diálogo tiene una lista de elementos a mostrar al usuario y un botón confirmar que cierra la interacción. Entonces tenemos: -carpeta utilities / helpers que contiene funciones reutilizables por toda la app -carpeta components -componente lista -componente diálogo (que puede mostrar otros componentes dentro y guarda el comportamiento de abrir y cerrar el modal) -carpeta pages -page contenedor que utiliza al componente dialog --componente button --componente dialog propia de esta page que utiliza al componente list y que va dentro del component reutilizable dialog. Espero haberte ayudado !!
@@cuaticito ahh y me olvidaba, .jsx para archivos que tienen html en su interior, .js para los otros. Y no trates de nombrar con el mismo nombre, que cada funcionalidad represente fácilmente por medio de un nombre fácil su funcionamiento
@@GentlemanProgramming El honor es todo mio .. Muchisimas gracias por tomarse el tiempo para darme el consejo profe, algún día, cuándo tenga, estaré aportando para que este canal siga creciendo como merece. Saludos.
Genial. Oye y qué tal tener a primer nivel una carpeta modules, y que cada módulo tenga su subset de carpetas de componentes, servicios, utilidades, etc. De manera que si quiero agregar un feature o modificarlo, busque dentro de módulos ese feature. Claro que podría ponerse una carpeta shared que sería un módulo compartido que por si mismo nos advierte que está comprometido con otros módulos. Y en el caso de features donde no sea claro si es de un módulo o de otro, simplemente sacamos un nuevo módulo específico para esa combinación de responsabilidades (un poquito como el bounded context del backend)
Muy interesante el vídeo, siempre he sido un desarrollador backend y estos últimos meses he estado estudiando y documentándome mas de lleno sobre el frontend, me gusta mucho React JS, me recuerda mucho a Blazor de .NET, también el tema de los web components con librerías como Atomico JS, son geniales, en general tu contenido me ha servido mucho, pero siento que hay un pequeño detalle en este vídeo que no me termina de ajustar y es el tema de la independencia de los frameworks, ese es un pilar importante dentro de las arquitecturas limpias, al igual que la regla de dependencia, en el caso de esta propuesta se rompe, al agregar Redux y Context dentro de Modelos/State (que representan el dominio) y eso hace que el Dominio quede amarrado al framework :/ Saludos y gracias por tus vídeos
Hola Freddy ! Estoy con vos en lo que dices :) Como decía justo a otro comentario que me notificaba lo mismo, es que no es clean architecture de un proyecto completo o en su total expresión sino el cómo implementar sus conceptos principales desde el lado del front para poder orientarlo a DDD y hacer separación de funcionalidades por capas. La idea principal era de tomar los conceptos de clean architecture, sumarles mi experiencia y con esto obtener una buena estructura para un project de Front :)
@@GentlemanProgramming Me imagino que sería posible abstraer un poco más y hacer las carpetas de "redux" y "styled-components", por ejemplo. El miedo al cambio siempre estará ahí en caso de acoplar la arquitectura de la app a una librería en concreto, por lo que en proyectos a largo plazo este podría ser un tema a debatir sin duda alguna.
IMO redux no debería ir en la capa de dominio porque el dominio debe estar lo más desacoplado de terceros lo más que se pueda. Redux, React-Query, entre otros en realidad son adaptadores o parte de la capa de framework. La idea de la capa de dominio (entidades, repositorios y casos de uso) es que pueda mantenerse inmutable si es que más adelante se decide cambiar de stack.
Excelente video , ya voy avanzando en la lista de videos , el materia es buenisimo y se agradece que lo expliques tan bien , me gusta el enfoque que tiene y demas, un saludo !
RU-vidando info sobre Clean Architecture y paf! Me encuentro con este canal y este videazo! Muchas gracias por este tremendo contenido, nuevo suscriptor por acá! 👏🏼👏🏼
Se agradece el material y esta muy bueno, pero deberias pensar en desacoplar el core/dominio de la app, de redux/context y moverlos hacia una capa exterior. En su lugar se podrian usar clases e interfaces, ya que ahi aplicarias mejor el concepto de que el dominio no dependa de librerias o frameworks. El grueso del trabajo ya lo hiciste pero podes seguir puliendo la estructura para brindarnos y brindarte mejores practicas (mas alla de que en la practica se puedan modificar), lo cual se agradeceria muchisimo. Exitos!
@@cejaramillof muy recientemente empecé con la idea de usar clean architecture con react (más precisamente next.js y typescript). Por lo que entiendo podrías generar interfaces y clases para representar el dominio de la aplicación, que en general coincidiría con el estado. Esa capa central desarrollada sólo en js o ts, sería importada como dependencia en la capa externa, por lo cual para el dominio ya es totalmente desconocido si en el proyecto se usa con react, vue, angular o js vanilla. Lo ideal sería que tanto los componentes de react como las llamadas al exterior (apis, blockchains) queden en la capa más externa, pero bueno como te digo todavía es una idea que no pude poner en práctica, me falta madurada más aun.
Primer que nada sos un genio todo muy clarooo Después, 2 preguntas: 1: puedo aprender react con hooks sin ver la manera tradicional sin hooks? 2: de que parte de la argentina sos ?? Jajaja
1- si que puedes ! Pero conocer la forma original puede abrirte bastante la mente a cómo funciona React. 2- soy de la ciudad de Mar del Plata en Buenos Aires !!
Buenísimo, es lo que mas anduve buscando. Generalmente los tutoriales son muy básicos y está bien para aprender la herramienta, pero no se explican las arquitecturas, qué significan, qué conviene y no conviene, y eso es lo que piden en la mayoría de los puestos de trabajo. Me gustó mucho tu vídeo, y me gustaría ver tus próximos vídeos, me suscribo!
Excelente contenido y muy buena forma de explicar la clean architecture, además de react y angular, es totalmente aplicable a Vue que es algo que hacemos en el trabajo. Lo que te quería consultar es acerca de la utilización de funciones factory para crear objetos, no vi algún directorio para eso en el ejemplo. Lo haces por medio de los adaptadores también? Saludos y muchas gracias por lo que haces para la comunidad
Buena pregunta ! En mi caso lo hago dentro de models ya que se encargan de crear objetos nuevos siguiendo una estructura que los representa (por ejemplo la class que está creada para los observables en el vídeo, es una factory de un solo tipo de objeto por el momento). Muchas gracias por tu mensaje !!
Alan , aparte de los 2 videos de Clean , tienes alguno otro que tambien pueda servirme de ejemplo para mi organizacion de carpetas y creacion de componentes y demas bien organizado?
@@GentlemanProgramming Yes , me la estoy viendo en orden voy un poco más de la mitad, solo queria saber si habia algo asi especifico a eso de las carpetas , pero seguiré el orden de los videos , gracias Alan
Buenas! Excelente Video. Una consulta eso si. Las funciones mas genericas que se utilicen en toda la app (algo como por ejemplo, validar un string) irian en la carpeta de utilities cierto ? Saludos !
Muy bien video! Yo soy un brasilenio y no tengo mucho gusto en el conocer espanhol pero tu vídeo me ayudó demas! Voy a aplicar este conocimiento en vue. Gracias!
Yes, para un project personal esta perfecto, el problema es al trabajar con diferentes compañeros de diferentes seniorities. Al incrementar la complejidad podemos traer problemas para nuestros compañeros ralentizando la velocidad de desarrollo. Pero estoy totalmente de acuerdo !
¡Genial vídeo, gracias! En lo personal, también prefiero agrupar por feature, sobre todo en proyectos grandes en donde haya proyección para ser micro frontends o monorepo. Adicionalmente, por feature tengo básicamente las siguientes carpetas: - repositories - servicies - models - libs - state (si la feature necesita redux) - presentation: donde van los containers/pages, componentes y hooks. Me gusta agrupar todo lo relacionado a UI en la capa de presentación y dejar lo relacionado a lógica de negocio en carpetas sueltas.
Exacto, aquí lo que hacemos es implementar los conceptos de Clean Architecture para hacer nuestro front, si vamos a implementarlo en un proyecto como tal, el front debe ser totalmente agnóstico e intercambiable a necesidad
Si lo más importante de la Clean Architecture es que la organización de la aplicación "cante" cosas sobre el negocio de la aplicación y no sobre los tipos de sus artefactos, no sé cómo eso va a encajar en la estructura que este chico sugiere. Yo creo que más o menos tiene la intención de hacerlo bien pero le faltan muchos años de experiencia aún para poder hablar sobre arquitectura. Se deja lo más importante como son la inyección de dependencias, inversión de control, etc... básicamente se deja fuera todo lo importante de la Clean.
Hola Gordon ! Perdona es que no puedo meter todo en un solo vídeo ya que los que recién empiezan se van a perder y esta es solo una estructura para la parte front end basándose en la clean architecture. Mi idea es que con la experiencia juntada dentro de mis 10 años de carrera, generar un project lo más genérico posible que pueda ayudar a cualquiera a crear algo escalable y bien estructurado basándose en los conceptos de la clean architecture. Nuevamente está solo orientado al front por eso digo de utilizar los conceptos ya que la clean architecture se usa para un proyecto en su totalidad y se abstrae de lo utilizado para la UI. Espero haber aclarado un poco !
Una consulta, supongo que los adapters los usas dentro de los services, ya que a los componentes le interesaría trabajar sobre el modelo del frontend no con el del backend. Pregunto xq en tu ejemplo del service retorna lo que devuelve el backend directamente. Por lo demás, muy buen video!
Depende ! Puede ser que un componente requiera de un formato diferente de la misma información por lo que usar el adapter en el componente mismo también es buena idea. Por ejemplo en mi caso me ha pasado que la misma información de usuario se adapta de diferente manera acorde al componente que la utilice :)
Lo el adapter es medio verso.. Lindo para la teoría.. en mi época del 2010 cuando era un ortodoxo de arq... peleaba por estas cosas ahora ya No. .. Si algo cambia tarde o temprano tenes que tocar lo mismo código y en cada fucking adapter que este afectado.. A la larga son más cosas q temes q desarrollar.. no el 100% de clean está bueno y no el 100% de clean es nuevo.. solo tine otros nombers Sobre redux .. por otros rincones se super ultra NO recomienda.. y al fin … tiras un F5 y el context o state se va,. Mételo en storage al loging y chau.. (cifrado)
Comparto ! Muchas de las cosas hay que tenerlas en cuenta dependiendo del contexto donde uno se encuentre. En mi caso el adapter me ha salvado muchas veces por cambios en los contratos con back. Pero siempre es lo mismo, adaptar los conceptos dependiendo de las necesidades que se dispongan. En mi caso soy fiel amante de usar rxjs y chau jajaja pero redux la verdad que para facilitar las cosas a mi equipo se ha dado de manera mas natural.
@@GentlemanProgramming Sip.. con clean ahora esta Escrito lo que antes te dabas cuenta con los años El Adapter no es mas que lo que en los 90 llamabamos Mapper o wrapper que es un conectoar proxy (no porxy web) entre una tecnologia y otra. (hacia algunas cosas mas) Ej cuando usabamos VB 3.1 y consumiamos datos proveniente de una BD en COBOL. Ahora tenemos un libro de R c. Martin (gracias a dios) que al fin dijo o tiro un listado de problemas comunes sobre andamiaje y desacoplado de nuestros componentes.. Muy buen video
Va a seguir habiendo contenido de Angular como también de otros frameworks, es que al trabajar a veces 12 horas al día no me da tiempo a crear todo el contenido que me gustaría y voy por partes satisfaciendo a todos los que pueda :(
@@GentlemanProgramming No hay problema profe. Se hace lo que se puede... Y aparte contaste hace algunos videos que estabas trabajando con React en tu trabajo y la gente lo pide, así que valga para que yo también aprenda React - Sigo recomendando tu canal a todo el que puedo.
Hola ! No debería de haber problemas :D ya que en si la carpeta que tiene NextJs para situar las vistas puedes tomarla como mi carpeta pages y continuar usando la misma estructura :)
Existe alfuna alterntiva a context para manejar el estado y funciones en una simple pantalla? Me parece un poco engorroso temer que estar creando el context y queria saber si existía alguna alternativa
Es la forma más clásica, también puedes usar Redux pero puede ser un poco más engorroso. También tienes Zustand que es una alternativa más liviana y simple. Pero creo que lo mejor para tu caso sería utilizar Jotai
Sos un genio, no solo que compartis contenido de calidad si no que transmitis de una forma divertida y se te entiende al 100%. Hay algun libro donde se vean explicado a detalle estos conceptos en react?
Gracias miles por el comment y la buena vibra ! la verdad que lo que expliqué es más un rejunte de mis experiencias y conocimientos que fui aprendiendo en el transcurso de los años, la verdad no sabría decirte, si alguien lee este comment y sabe de alguno que lo pongaaaaa
Todo bien bro, pero creo que deberias hablar de una arquitectura mas bien agnostica al framework que es lo que busca una arquitectura limpia, de modo que una app sea modular sin utilizar react necesariamente. Y al combinar conceptos propios de react como hooks o redux, ya estas limitando al uso de este, cuando en realidad la arquitectura hexagonal que propone se usa con interfaces para evitar atarse al framework
Hola! La idea del vídeo era de implementar los conceptos de la clean architecture solamente en la parte del front para poder estructurarlo con buenas prácticas adaptándolo con mis experiencias :) es más o menos lo que digo al principio del vídeo
¡Buenísimo el video! Messirve. Una pregunta que me quedo, yo en los proyectos a las interfaces de un componente lo dejo en el mismo archivo, si necesito la misma interfaz en otro componente lo pongo en ts/types.ts Ahora no sé si sería ahí o en la carpeta models/
Hola ! yo siempre recomiendo ponerlo en otro archivo, en este caso en la carpeta models para tener todo en el mismo lugar y respetar la capa "domain" :)
En el caso de los adapters, no afectará en el rendimiento de la app si por ejemplo se reciben muchos datos de un arreglo de objetos por ejemplo. A lo mejor unos 50 datos aprox y estarlos mapeando uno por uno
Creamos una app en React ! buenas prácticas, clean architecture, redux, context y Typescript ! ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-p9PAmqpCWgA.html
como me gustaria laburar en un proyecto tuyo, estoy podrido de participar en proyectos gigantes sin estructura, gracias a tus videos estoy aprendiendo mucho de arquitectura y espero con el tiempo poder aportar estos conocimientos en los proyectos de la empresa en la que estoy
Vengo de Angular a React 😅, me gustaría hicieras un video explicando como reutilizar componentes en React, un ejemplo más especifico sería un input o un select que se usan muchísimos en una app, pero que el componente en sí tenga la lógica para ser validación y demás según el prop que se le envíe... así como el componente que explicas en el ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-5LqhlCd2_nE.html
Muy muy buen video, tengo una cónsulas si uso nextJs como hago con las tarjetas pages, es mas con componentes que se usarían solo en una page en particular , saludos
me gusto mucho lo del adapters, es una capita más en la ui que te ayuda a como vos decis a no hacer el cambio en toda la app .. en el proyecto donde estoy no lo estamos utlizando
No te preocupes ! No muchos lo hacen, pero yo una vez que lo aprendí no pude dejar de ver su importancia. Unos cuantos devs me han dicho que luego de este vídeo ven adapters everywhere hahha
Incluso en services pudiera separarse un poco mas la instancia de Axios en otro archivo y ahi tener las base url, no pasarla, si no tener esa estructura para tener varios archivos de varias instancias de Axios para conexiones de otras API y que cada una pudiera tener alguna cosa extra en los headers (Por decir algo), algo asi yo lo separaba en usando Vue + Vuex y es la estructura que recomendaba Evan You
Yes ! Es una buena forma de hacerlo. En mi caso generalmente tengo las base url en los archivos env, ya que cambian según el environment que utilicemos y luego podemos tener bien como tu dices ficheros que manejen las diferentes rutas. Todo depende de que tanto necesites :)
Te hago una consulta, como se utilizaría un adapter? Llamas primero a tu service y le pasas el retorno al adapter desde tu componente? O directamente dentro del adapter llamas al service?
Hola ! El adapter se llama dentro de la lógica donde llamas al service, sería algo así: 1- inicializas tu componente 2- realizas la llamada al endpoint 3- utilizas el adapter en el resultado 4- profit Espero haberte ayudado !
Si muchas gracias, estoy encarando un proyecto de refactorizacion de un proyecto medianamente grande y la verdad que este video fue de mucha utilidad. Cómo sugerencia estaría bueno un vídeo donde vayas explicando el flow de una aplicación normal. Que vayas mostrando como utilizas cada tipo de archivo y como interactúan mutuamente. Me pareció super clara tu forma de explicar en comparación a otros canales. Mándale que vas de 10, muy bueno.
¿Esto se puede aplicar de la misma forma con Next? Sería bueno ver un video sobre esto con Next ya qué han sacado de la documentación el create-react-app y ahora recomiendan el uso de otras herramientas como Next o Gatsby
Yo en lo personal no recomiendo esta arquitectura al menos que tu empresa cree únicamente un software propio, de lo contrario esto hace que NO puedas reusarse tu components o paginas en otros proyectos, yo recomiendo a styled-components con Atomic Design de esa forma llevar un componente a otro proyecto es tan simple como copiar y pegar la carpeta que almacena el componente ahorrando mucho tiempo en debugear
Hola! Justo recomiendo usar styled componentes :) esta arquitectura la he utilizado en múltiples proyectos y también da a la posibilidad de utilizar librerías propias para la integración con componentes reutilizables 😊 Justamente trata con la capacidad de hacer el código lo más independiente posible y de esta manera incrementa la re utilización de lógica.
Hola gentleman, tengo un incoveniente que vos talvez me podes ayudar. Quiero sacar el ../ de los imports, entiendo que hay que hacer una configuración en el tsconfig.json porque en next lo hago y me deja, pongo baseUrl:".", y ahí me deja hacer el import así: import {Component} from "components"; Pero en react-vite no me funciona, sabes porque? Con react-cra no probé aún. Busqué en google y nada, por eso pregunto jajaja Saludos!
Gracias por el contenido. Se agradecen nuevos puntos de vista y en muchas cosas estoy de acuerdo. Pero falta por desacoplar frameworks en la logica para considerarlo clean architecture. Sin embargo me suscribo, muchas gracias!
Yes ! Es que no es clean architecture de un proyecto completo sino el como implementar sus conceptos principales desde el lado del front para poder orientarlo a DDD y hacer separación de funcionalidades por capas :) welcome a la comunidad !!
