Para mí, tener los sufijos separados con un punto es más práctico. Con un solo vistazo en el tree, ya sabes qué cosa es qué, sin tener que entrar en cada archivo. Además, puedes agrupar los archivos en VSCode y en Web Storm más fácilmente. De hecho, uso los sufijos con punto para muchas cosas. Como los pipes, módulos, modelos, datos, api body, etc. Tener cada archivo con el mismo nombre, pero cambiando el sufijo con un punto hace más fácil agruparlos que usando un guion.
Esto mismo. Me gustó la idea de que le empiecen a dar mas bola a single file components (con lo de no sugerir por defecto dividir los components en 3 archivos) y la idea de variar el nombre de los services en base al propósito (algo que yo venía haciendo para distinguir servicios de http clients, de manejo de estado y de lógica por ejemplo). Pero en ese punto de quitar los sufijos creo que la pifiaron.
Seria bueno que compartas esta opinion con el equipo de angular en el RFC :), personalmente espero que puedan resolver el posible problema de herramientas que usan los sufijos para detectar que es codigo de angular
Me gusta mucho la idea de no separar el template html del ts. En lo personal ya era algo que había hecho en un proyecto y me gusto mucho, en comparación de tener 3 archivos por componentes. Sin duda Angular esta tomando un camino increible, yo empece en la versión 15 y ya estamos en la 19 y sin duda si he notado que algunas cosas son mas sencillas. Gran video 😉👍
Muy buen por el resumen, aun viendo el live de presentación no entendía eso de los nombres pero tu si pusiste ejemplos! Sobre lo del boton no se si por usar nx le sumó mas, pero no debería ser tantos archivos, serian solo 3, el ts,html, scss y como es standalone importarlo en donde se quiera mostrar, o no se si 3 archivos se le hacían demasiados
@@masterterricola gracias por tu comentario uwu, es verdad que nx le puede agregar una capa extra de complejidad pero de todas formas para las personas nuevas les puede parecer demasiado jeje
Muy bien video, opino que el cambio en la forma de llamar los archivos se me hace bien y en cuanto al posible cambio de sintaxis parecido a los SFC de vue estaria aun mas mejor ya la ventaja estaria al momento de desarrollar microfrontends.
Hey buen resumen! 1- los cambios de naming están bien, pasan de usar . a usar - en la mayoria de casos, lo cual hay que acostumbrarse. 2- la razón por la que a dev que vienen de otros frameworks les incomoda tanto archivo es porque no hay un cli que autogenere todo eso. Claro si en angular tendríamos que hacerlo todo a mano seria horrible, pero como cli es totalmente configurable entonces por eso es que uno de acostumbra 😊
@@CarlosMoralesDev me parece super bien, te llegas acostumbrar. Sin embargo, el tema creo que es el tener todo en archivos separados mantiene la responsabilidad única. Claro, todo los componentes debería ser pequeños, pero en react me ha toda ver esos componentes que son horribles porque no entiendes con todo lo que tiene el componente
Personalmente me gusta mas el orden que se maneja en angular ya que sabemos donde esta todo separado y ordenado darle un enfoque como react me parece mas laxo cuando hago algo en react siento como si estuviera en un proyecto del colegio encambio la infraestructura de angular me da otra sensacion, la opcion siempre es dejar las dos formas para angular laxo y fuerte podria decirse pero si intentan poner angulsr solo como react para mi seria un problema ya que vuelve a los codigos espaguetis y quedaria como dart con flutter ademas de perder la escencia principal de angular que es infraestructura clara y empresarial
Angular es maravilloso, la estructuracion puede parecer mala al principio, pero ayuda muchisimo a que todo funcione perfecto sin mezclar nada ni hacer los tipicos codigos spageti. Yo siendo un novato, pude crear sin problemas un e-commerce completo, casi sin errores. No me gusta esta filosofia de tener que adaptarse para parecerse a otros frameworks, Angular debe mantener su status de framework de alta calidad
Angular me hace recuerdo a Spring el framework Java que era el más usado y odiado a la vez por todo su boilerplate pero luego pasó a ser el más amado con Springboot por q eliminó todo esa maraña de cosas innecesarias
Angular es para grandes empresas, para desarrolladores experimentados, un poco de boiler plate no es grave, grave es un código mezclado y desordenado, espero que no tomen malas decisiones solo para agradar a los más novatos
Entiendo tu punto de vista, la verdad que en el RFC habian muchas personas mencionando eso, pero algo interesante es que estas son sugerencias, por ello podemos optar por usarlas o no :)
lo de los nombres es confuso mejor seguir agregandole component, service, directive, ya que quiero reconocerlos al ver el nombre y no tener que entrar al archivo para ver su decorator... es absurdo y una fumada de angular para mi. En proyectos compactos pequeños, podria ser pero para proyectos medianos y grandes solo crearas confusiones en tu estructura.
@@edgardomolinagonzalez3121 creo que no puedo poner el link directamente pero si vas al github de angular, en las discusiones vas a encontrar el RFC, y ahí puedes dar tu opinión 😉
Algo que me gusta de angular es que te enseña a modularizar y me gusta mucho tener el template separado del ts.
Entiendo tu punto:) si deseas trabajar así no hay ningún problema, sobre todo por que angular es retrocompatible
@@CarlosMoralesDeves uno de los puntos fuertes de Angular el tener cada cosa separada
Gracias por otro video ;)
Gracias por tu apoyo
Para mí, tener los sufijos separados con un punto es más práctico. Con un solo vistazo en el tree, ya sabes qué cosa es qué, sin tener que entrar en cada archivo. Además, puedes agrupar los archivos en VSCode y en Web Storm más fácilmente.
De hecho, uso los sufijos con punto para muchas cosas. Como los pipes, módulos, modelos, datos, api body, etc. Tener cada archivo con el mismo nombre, pero cambiando el sufijo con un punto hace más fácil agruparlos que usando un guion.
Esto mismo. Me gustó la idea de que le empiecen a dar mas bola a single file components (con lo de no sugerir por defecto dividir los components en 3 archivos) y la idea de variar el nombre de los services en base al propósito (algo que yo venía haciendo para distinguir servicios de http clients, de manejo de estado y de lógica por ejemplo).
Pero en ese punto de quitar los sufijos creo que la pifiaron.
Seria bueno que compartas esta opinion con el equipo de angular en el RFC :), personalmente espero que puedan resolver el posible problema de herramientas que usan los sufijos para detectar que es codigo de angular
Me gusta mucho la idea de no separar el template html del ts. En lo personal ya era algo que había hecho en un proyecto y me gusto mucho, en comparación de tener 3 archivos por componentes. Sin duda Angular esta tomando un camino increible, yo empece en la versión 15 y ya estamos en la 19 y sin duda si he notado que algunas cosas son mas sencillas. Gran video 😉👍
Gracias por el apoyo, la próxima semana un nuevo video con las novedades de angular 19!
Buen video!
Muy buen por el resumen, aun viendo el live de presentación no entendía eso de los nombres pero tu si pusiste ejemplos! Sobre lo del boton no se si por usar nx le sumó mas, pero no debería ser tantos archivos, serian solo 3, el ts,html, scss y como es standalone importarlo en donde se quiera mostrar, o no se si 3 archivos se le hacían demasiados
@@masterterricola gracias por tu comentario uwu, es verdad que nx le puede agregar una capa extra de complejidad pero de todas formas para las personas nuevas les puede parecer demasiado jeje
Muy bien video, opino que el cambio en la forma de llamar los archivos se me hace bien y en cuanto al posible cambio de sintaxis parecido a los SFC de vue estaria aun mas mejor ya la ventaja estaria al momento de desarrollar microfrontends.
@@CarlosSalazar-sr1lu me encantaría usar la sintaxis de svelte o astro, se ve genial
Hey buen resumen!
1- los cambios de naming están bien, pasan de usar . a usar - en la mayoria de casos, lo cual hay que acostumbrarse.
2- la razón por la que a dev que vienen de otros frameworks les incomoda tanto archivo es porque no hay un cli que autogenere todo eso. Claro si en angular tendríamos que hacerlo todo a mano seria horrible, pero como cli es totalmente configurable entonces por eso es que uno de acostumbra 😊
El CLI de angular es potente! Que opinas de todo el codigo en un archivo? o un enfoque tipo Svelte
@@CarlosMoralesDev me parece super bien, te llegas acostumbrar. Sin embargo, el tema creo que es el tener todo en archivos separados mantiene la responsabilidad única.
Claro, todo los componentes debería ser pequeños, pero en react me ha toda ver esos componentes que son horribles porque no entiendes con todo lo que tiene el componente
@@danielbarrientos722 Es verdad tienes razon, va a depender mucho del desarrollador.
Personalmente me gusta mas el orden que se maneja en angular ya que sabemos donde esta todo separado y ordenado darle un enfoque como react me parece mas laxo cuando hago algo en react siento como si estuviera en un proyecto del colegio encambio la infraestructura de angular me da otra sensacion, la opcion siempre es dejar las dos formas para angular laxo y fuerte podria decirse pero si intentan poner angulsr solo como react para mi seria un problema ya que vuelve a los codigos espaguetis y quedaria como dart con flutter ademas de perder la escencia principal de angular que es infraestructura clara y empresarial
Entiendo tu punto de vista, lo bueno es que NO es obligatorio que lo hagas de esta forma y podras seguir trabajando como mas te guste :)
A mí me parece mucho mejor Angular que React, de hecho, me encanta más porque simplifica varias cosas, además de estructurarlas de manera organizada.
@@RubianoAndy es verdad pero siempre hay que explorar nuevos frameworks o librerías para seguir aprendiendo 😉
Tacho. Acaso el archivo module no había desaparecido en el 17 ? 🤔
Angular es retrocompatible, eso quiere decir que si deseas puedes usarlo, no va a desaparecer pero ahora se recomienda usar standalone
Angular es maravilloso, la estructuracion puede parecer mala al principio, pero ayuda muchisimo a que todo funcione perfecto sin mezclar nada ni hacer los tipicos codigos spageti. Yo siendo un novato, pude crear sin problemas un e-commerce completo, casi sin errores. No me gusta esta filosofia de tener que adaptarse para parecerse a otros frameworks, Angular debe mantener su status de framework de alta calidad
@@alexis-pz2ro gracias por tu comentario, de todas formas vas a poder seguir usando las 2 formas, esto solo es una sugerencia 😉
Angular me hace recuerdo a Spring el framework Java que era el más usado y odiado a la vez por todo su boilerplate pero luego pasó a ser el más amado con Springboot por q eliminó todo esa maraña de cosas innecesarias
❤❤❤❤❤
Angular es para grandes empresas, para desarrolladores experimentados, un poco de boiler plate no es grave, grave es un código mezclado y desordenado, espero que no tomen malas decisiones solo para agradar a los más novatos
Entiendo tu punto de vista, la verdad que en el RFC habian muchas personas mencionando eso, pero algo interesante es que estas son sugerencias, por ello podemos optar por usarlas o no :)
lo de los nombres es confuso mejor seguir agregandole component, service, directive, ya que quiero reconocerlos al ver el nombre y no tener que entrar al archivo para ver su decorator... es absurdo y una fumada de angular para mi. En proyectos compactos pequeños, podria ser pero para proyectos medianos y grandes solo crearas confusiones en tu estructura.
vamos a ver como evoluciona esto, de todas formas si tienes comentarios podrias dejarlo en el RFC de angular para que escuchen tu opinion :)
Sería mejor usar componentes funcionales con el decorador @component y retornar las directivas en vez de jsx.
Hey! Podrias sugerir eso en el RFC :) estaria bueno
@CarlosMoralesDev Donde hago eso jajaja
@@edgardomolinagonzalez3121 creo que no puedo poner el link directamente pero si vas al github de angular, en las discusiones vas a encontrar el RFC, y ahí puedes dar tu opinión 😉
Blazor con C# tiempo de desarollo MUCHISIMO menor
Intereasnte no lo tenia mapeado :)
No me gusta estos cambios, me parece que Angular es más ordenado que otros frameworks de javascript
Ojo, son sugerencias, si deseas las usas, si no puedes seguir trabajando como lo haces :)