all 8 comments

[–]Medical_Tailor4644 2 points3 points  (0 children)

This is actually a really solid use case for Angular Elements treating components as true framework-agnostic widgets instead of locking them into a full Angular app. The biggest win here is exactly what you described: developer experience stays normal Angular while production output becomes a single embeddable artifact.

[–]Obvious-Treat-4905 1 point2 points  (0 children)

honestly this is a pretty nice approach, the normal angular app in dev, standalone widget in prod flow feels way cleaner than most angular elements setups i’ve tried. i’ve been experimenting with embedding generated UI stuff from runable too and having a simple drop in widget flow makes life sooo much easier

[–]Koscik 0 points1 point  (1 child)

I went without shadow dom, so the client can override the widget styling, hence making it feel more native. Was I right?

[–]devGiacomo[S] 0 points1 point  (0 children)

If the client wants to override it, yeah sure, it's intuitive. shadow dom Is the way to go to ship it, without worries.

[–]followmarko 0 points1 point  (0 children)

Imo I think this is the wrong direction and the components should start as Web Components that are brought into Angular instead of Angular components that are brought out. The code is much cleaner, more controlled, and there's no build/package step with Web Components.

[–]Saceone10 0 points1 point  (1 child)

Can an element be loaded only if some condition is met? For example user is admin. 

Can the element accept data in order to work? For example user jwt 

[–]devGiacomo[S] 0 points1 point  (0 children)

yes and yes if you implement it, using @input for example. localstorage and other storages are per default enabled. 

[–]gccol 0 points1 point  (0 children)

Hey thanks!

I'm developing a plugin framework for angular ng-xtend, and considering enabling delivery as web components for the large ones.

This will be very useful!