No todo es STANDALONE Component - Jimy Dolores

[@AngularSpanish]

RESUMIENDO: Usar Standalone Component para la carpeta "Shared" donde se encontraran componentes independiente de uso general, como pueden ser breadcrumb, sliders, cards, como si de componentes Elementor estuviéramos hablando.

[@frochaol]

Que bueno que más personas de Perú compartan conocimiento de este tipo, saludos y buen video !!

[@DominiCode]

Gracias por comentar

[@jukahiga3363]

19:33 cuando se da el ejemplo de carga un módulo con 10 o más componentes usando lazyloading creo depende si los necesidad mostrar o no todo de una , me explico si tengo un módulo customer , y este tiene 16 rutas y en cada ruta se debe ten

[@otakujsdev]

hahhaha que GENIAL! yo tenia esta misma duda!! ahora los componentes tendrán un bundle especifico cerrado, si se repiten dependencias en los componentes hijos serán grandes por separado! oye gracias, un saludo desde Chile!

[@AntonioSantana-ll8il]

Excelente consejo, a veces nos dejamos llevar por la innovacion, sin darnos cuenta que no podemos irnos a un extremo, creo que podemos tomar lo mejor de los dos mundos, para crear una aplicacion organizada y mantenible. Adicional, angular nos da las opcion para todo gusto, o solo standalone o solo modulos y los dos y eso me parece super!

[@DominiCode]

Gracias Antonio 🤝🏻

[@aldoprogramming]

Don Jimy, un genio!

[@oliverdjbrown]

excelente charla ufff, me encanta como se salen de la caja pensando en porqué elegir entre módulos y standalone components cuando se pueden aprovechar las virtudes de ambas en un proyecto

[@DominiCode]

Encantado de ayudarte 😄

[@drackp2m]

Bua, me ha parecido increíble la charla. ¿Cuántos años tiene este maestro? He aprendido bastantes cosas nuevas de un solo plumazo, y eso que venía sólo a por lo de los Satandalone components.

[@DominiCode]

encantado de ayudarte 😊

[@tympo]

Alguien me podría explicar si el standalone solo se recomienda para componentes que se vayan a reutilizar en varios lugares ¿Por qué Angular los esta imponiendo a partir de la versión 17, siendo ahora prestablecido en la instalación por defecto?

[@carlosbracamonte4884]

Angular de ahora en adelante apuntará a standalone components, y la verdad es lo mismo, solo con cambio de nombre

[@DominiCode]

Correcto

[@edgardomolinagonzalez3121]

Me enredé todo jajaja ¿y si mejor eliminan los módulos y usamos solo standalone?

[@gatonegro2123]

Y como vas a manejar proyectos enormes?

[@edgardomolinagonzalez3121]

@@gatonegro2123 Como en React, modularizando por carpeta.

[@gatonegro2123]

@@edgardomolinagonzalez3121 mejor módulo y ngrx, para eso hazlo en react, si has visto un proyecto de angular de alguna consultora grande…te volverías loco

[@davidpinalopez7467]

@@gatonegro2123 React maneja proyectos de cientos y cientos de componentes y ni sospechan del concepto del modulo. Crear carpetas y sudivide el componente si crece

[@carlosbracamonte4884]

Pero si standalone viene a ser un modulo vestido de componente? Igual sirve para proyectos grandes

[@transforgoku]

Yo estoy aprendiendo Angular y la verdad estoy sufrièndole porque TS no me deja compilar (no me complico la vida asì que todo lo dejo en ANY) cuando quiero, y aùn estoy verde en cuanto a entender y usar RxJS se trata pero espero poder tener un dominio decente del framework dentro de los pròximos 6 meses. La developer experience con Angular para alguien como yo que recièn entra al desarrollo web es sobrecogedora y resulta frustrante la mayorìa de veces en comparaciòn con otros frameworks populares tipo React, Vue o Svelte porque Angular es bastante rìgido y opinionado lo que convierte su curva de aprendizaje muy inclinada para los novatos... Aparte de eso, excelente exposiciòn, yo tambièn creìa que hacerlo todo en standalone era lo màs òptimo para no tener un mòdulo sobrecargado con decenas de imports, pero no tiene sentido usarlo si solo voy a requerir de mi componente una sola vez en toda la aplicaciòn. Saludos.

[@betaniagonzalez1102]

Me lo perdí :(

[@DominiCode]

🥹

[@davidpinalopez7467]

Muy esclarecedor el ejemplo de Jimy pero no estoy de acuerdo. Los standalone componentes nos permiten entender de una sola mirada cuales son las verdaderas dependencias de ese componente. Con el anterior paradigma de módulos, todas estaban amontonadas en un módulo común pero de hecho NO sabías que dependencias afectaban a un componente o a otro. Si el argumento es que las dependencias de un componente pueden crecer en su propio import, eso mismo se puede aplicar al módulo que las contiene y en el caso del standalone component esta claro que la super población de dependencias te esta avisando de que ese componente quizá deberían ser dos o tres mas pequeños. La solución no debiera sera apilarlos en el cubo de basura del módulo que le toque sino subdividirlos en componentes con significado. Por otro lado Jimy, que se nota que sabes un montón del Angular vaya por delante, a veces no es tan fácil discernir si un componente va a depender de otro para siempre jamás, muchas veces es una decisión de la que más adelante te lamentas el no poder reutilizar en otra parte. Esta era la gran ventaja de React y que yo creo ahora Angular se ha puesto por fin a su altura. Si no me equivoco, de los frameworks principales, React. Vue, Svelte, Qwik, etc, Angular es el único que tenia este concepto de modularización

[@andresfcuellarc]

Estaba convencido que no se podia combinar!

[@DominiCode]

Pues sí

[@leo123juan]

????

[@DominiCode]

Hola, Leo