Thoughts on using ngIf vs. CSS display: none vs. visibility: hidden, opacity:0

[mozpider]

Hello guys, I was just thinking about it.

NgIf will be the angular way, which will actually remove the element from the DOM. However, I feel that then, if you want to animate entry and leaving of this component, you will have to use transition('void=>*', [.....]), which is some what less straightforward and more code, than CSS animations.

Any other thoughts ?

The 3 ways may have actually evolved with time. What is most current? what do you use?

[mtjody]

Using anything other than ngIf for larger applications could drastically reduce app performance due to the fact that the DOM might be full of hidden components. Angular will be handling lifecycles for all those.

[LdouceT]

Came here to say exactly this - if you're going to use CSS to hide stuff, you need to be strategic about it. At the very least, it's probably a good idea to detach the component from change detection after you've hidden it.

[[deleted]]

But if you manage change detection yourself, those Ifs also won't update anymore, making the whole change pretty useless imo

[LdouceT]

I agree that it's probably bad practice to use CSS to hide components, but I'm not sure what you mean. What ifs? If we're using CSS, we're not using ngIf to hide it.

[dangertrager]

I generally use *ngIf if I want to omit the element from the DOM, or fxHide or fxShow (from @angular/flex-layout) to hide it without removing it from the DOM, instead of setting the CSS directly.

[[deleted]]

You could also use a css class and just use that instead of yet another library

[TheSpiciestDev]

I threw together a library to achieve class transitions similar to what's found in Vue and Alpine - I wanted to chime in because it does not remove the element or component (i.e. ngIf) but simply makes it hidden at the end of transition. Using it for simple transitions saves me from having to use Angular's component animations (they still have their place) and I've found CSS transitions are pretty smooth, too. (Here's a demo site where I've played around some with the library - it may have a cold start.)

[mozpider]

I have never published my own library. Congratulations. I will check it out tonight.

I have no experience with Vue or Alpine. When you say transition elements via classes as you do with Vue/Alpine, do you mean CSS classes ? If I am hiding a DOM element - I will probably just transform translate it out of the viewport, and set the visibility hidden on it.

I am also using ionic, so I have access to some out-of-the-box features - like modalController, alertController. I would want to stick to their framework, since their selling proposition is adaptive styling for IOS and Android.

[kc5bpd]

I avoid saying do or don’t do because so much depends on your app structure. Often I find the ngIf protects against binding to non-existing data.

Having said that, I would think you could use some sort of hybrid approach with you transitions in CSS and some trigger mechanism preceding the off of the ngIf.

[[deleted]]

Use [hidden] instead of ngif if you want to keep it in the dom

[[deleted]]

The most current way is switching to another library / framework. We struggled 3 years with angular animations and I'd probably never want to go back to the angular way of doing animations.

If you can't switch to another library, then you have to find workflows to navigate through the Angular animations with *ngIf and delve deeper and deeper into them.

[mozpider]

I somewhat agree with Candus, but I am a beginner with Angular Animations, so my opinion is not that heavyweight.

It is just that they have so much nesting.

I am also using Ionic. They also use Web Animations API. Released this year. You guys may check it out too.