NgComponentOutlet in Angular - DECLARATIVE Dynamic Components

[@DecodedFrontend]

To try everything Brilliant has to offer-free-for a full 30 days, visit brilliant.org/DecodedFrontend. You’ll also get 20% off an annual premium subscription.

[@returncode0000]

You are one of the best Angular instructors, I really love the clarity on how you explain things, great job!

[@gund_ua]

Nice video as usual Dmytro! Finally, 7 years later, angular added this to the core and my library can be deprecated (once outputs are added as well).

[@DecodedFrontend]

Thanks, Alex! Your library is fantastic and was happy to recommend it to everyone who neede to handle complex use cases with dynamic components! 🙌🏻

[@alphamarouanadiallo8238]

Thanks again !

[@haroldpepete]

Damn, the last part was impressive, you're the angular man, thanks. I would like to watch a video about how get user preferences from the backend, then hide or show features depend on user priveleges and preference, and if you may use guard in routes, it would be nice

[@vamvdotnet]

Great demo!!!

[@maximvoloshin7602]

Thanks for limitations. Great video!

[@DecodedFrontend]

Thank you 😊

[@ahfazrahman9328]

Thank you for the wonderful content @DecodedFrontend.

[@manuelhohagen4441]

Another amazing video! So many thanks!!

[@gagiksimonyan3782]

Thanks Dmytro for another useful video)

[@AnamariaNanes]

Thanks!

[@DecodedFrontend]

Thank you so much for your support ❤️

[@DraaElMizan]

Another amazing tutorial. Thanks Dmytro.

[@musoverda]

thank you! another interesting and useful video! this time - do you use protected as an alternative to private? ) i like this approach more than the # symbol

[@Nabulio85]

Really great. ❤

[@albertoalbericio6163]

Do you know if you can use [ngComponentOutletInputs] to chain Inputs? I mean, instead of defining a static string value for the input, bind it to a real Input in the creator component. Thanks for your video.

[@alexander-3701]

@DecodedFrontend How would you prevent loading unused components from the map?

[@DecodedFrontend]

Using the import('./component-path') to lazy load them :)

[@alexander-3701]

@@DecodedFrontend Another question. :) How would you approach this case but with micro-frontends?

[@ytamb01]

@@DecodedFrontend yes. your widget keys could be the component-paths so you don't have to import them up-front?

[@oleksiipopov5143]

Thank you! It was realy usefull video!

[@DecodedFrontend]

Glad to hear that! Thank you!

[@spamdump7337]

why Type instead of WidgetComponent?

[@FriendlyAce]

Are your courses also available on udemy?

[@DecodedFrontend]

Hello, Unfortunately, I moved from Udemy and my angular courses are not available there.

[@NiGhTm4r389]

There is no [ngComponentOutletInputs] (anymore?). Instead I have to use ngComponentOutlet as a structural directive: *ngComponentOutlet="component; inputs" Is this video still up to date? Also, is it possible to strictly type the inputs so I don't just put random stuff in there? I imagine having like 5 different components, that another component, which has the directive can use and they all have different inputs. I kinda want a type or interface that says "this component has these inputs". Is that possible?

[@MrVinodkumar92]

How can we get the widget component class without defining so that the component is not dependent and everything can be lazily loaded.

[@ahmedshehata4143]

I have an Angular application that uses lazy-loaded modules. One particular module contains a lot of components that depend on user input, where only one component is visible at a time based on the user's choice. I am experiencing issues with managing the visibility of these components. Currently, I am using CSS classes to hide/show components, but this approach leads to problems when interacting with visible components. When I use the *ngIf directive to conditionally render components, it works correctly but may cause performance issues as it triggers re-rendering of components each time the user changes their input. How can I efficiently manage the visibility of these components to improve performance while avoiding unnecessary re-rendering?

[@stefanstanchev5315]

Great demo, but may I ask something? Why you prefer to create and re-assign properties instead of using signals?

[@DecodedFrontend]

Hi :) Since it is a tutorial, everything that is not related to the topic directly, I simplyify as easy as possible to reduce unnecessary cognitive load. You should not treat it as a production-ready code.

[@stefanstanchev5315]

​@@DecodedFrontend Sounds valid. However, from my perspective, many would be interested in seeing how you would implement this piece of code. Signals are straightforward, yet they remain a core part of Angular functionality. Kudos for all the great work you’ve done and continue to do!

[@oWeRQ666]

They'll do anything not to use the virtual dom.

[@bukanaka]

Атомный контент подъехал!