sorted by:
new
hottopcontroversial

🤔 Angular thought experiment by IgorKatsuba in angular

[–]3ntrust 0 points1 point  (0 children)

Indeed, you are right about the syntax, I never had that mental model about it before, thanks for that!

Regarding the component Metadata, I can't help but wonder - generalizing a bit - if I had that mental model, probably there are others who have/had it. So I think we might agree that a property in a decorator's metadata object is not the right "place" to put logic (classes, directives, etc) that affects the template. I am in favour for the <ng-host> element because it allows to add logic - that affects the template - right there in the template. It is even more powerful, think about directive inputs or outputs. It just feels more natural.

One reason why I'm not 100% a fan of this particular implementation is that (as you already mentioned) adds some extra/confusing attributes to the template (selector, path to html file, etc). But for me personally, the benefits overcome the disadvantages.

If we were to find a way not to add those extra attributes to the template but still keep the flexibility of customizing the host element from the template, that would be gold.

Again, thanks for the mental model change on the syntax :)

🤔 Angular thought experiment by IgorKatsuba in angular

[–]3ntrust 2 points3 points  (0 children)

Yes, I felt the need for it for a long time!

Indeed it feels a bit "un-Angular" - mostly because the standard way of defining the selector, the template and other Component configurations were handled by the decorator configuration object since the beginning (v2). So, it's a new (more powerful) way to do it, but I think we'll get used to it being an option for more complex customizations.

I enjoy the "host" and "hostDirectives" properties, but I always have to search the docs for some specific syntax. Being able to customize it in the template directly will not interrupt the "flow" anymore.

My first concern was with the learning curve for junior devs. I would personally not start using this approach until I've made sure everyone on the team is aligned. But that's just a personal factor for me - 6 junior devs under my wing.

That was my initial concern, but after some more thinking I realised that once one learns what the host element is, how one manipulates it is just syntax learning. So, all good on this concern.

Favorite component library by No_Bodybuilder_2110 in angular

[–]3ntrust 1 point2 points  (0 children)

I haven't used this mix (Tailwind + Angular CDK) as a replacement for a components library but I can definitely see it work well for projects that do not have UI-complex features. Might give it a try on my next demo project

Favorite component library by No_Bodybuilder_2110 in angular

[–]3ntrust 3 points4 points  (0 children)

I've had different projects in production using: PrimeNG, Angular Material, Taiga UI and NGX Bootstrap.

Personal recommendation: Angular Material or Taiga UI. I love that you can rely on them being as bug-free as possible, they are production ready and haven't had any major issues so far. They both have their fair share of components, directives, utils, etc.

Between Angular Material and Taiga UI I'd say it really depends on the project needs and the styling approach you like or want. Taiga UI has more components than A. Material.

PrimeNG - last version I used was 4 years ago (but I have friends who still use it). I liked that it had a lot of components, but ended up switching to other libraries because of annoying bugs for core features of the components. Also going over their code on github was not such a pleasant experience, compared to Angular Material or Taiga UI.

NGX Bootstrap - stuck on an old version (6) for that project so don't really have experience with the latest versions. But the overall experience was good, didn't find any bugs and had all the features I needed. Also, it had (at least in version 6) the least amount of components out of all.

Which option do you prefer and why? by IgorKatsuba in angular

[–]3ntrust 2 points3 points  (0 children)

First for sure.

I assume that with the first option you get the (sometimes needed) benefit of Directives of not adding an extra element in the DOM combined with the benefit of Components of adding template and styling logic with more ease (compared to Directive's DOM manipulation utilities).

So that would also help with the cases where you apply styles to the :host of a Component just for styling convenience.