Don’t Use the Hidden Attribute with Angular 2

Angular 2 moved towards an organized and predictable access to the DOM. Meanwhile, the concern was particularly about visibility in building UIs. A common mistake made by developers is that given the long association they have with HTML and AngularJS 1.x, they believe they can use safely hidden attribute anytime. However, mostly hidden does not break, giving developers an illusion that everything is fine and fun once they have done little bit of rote coding. Though hidden in Angular 2 can create confusion for many upcoming days when tight coding might become more biased and undesirably hard to transcribe logically over time.

Angular 2 moved towards an organized and predictable access to the DOM. Meanwhile, the concern was particularly about visibility in building UIs. A common mistake made by developers is that given the long association they have with HTML and AngularJS 1.x, they believe they can use safely hidden attribute anytime. However, mostly hidden does not break, giving developers an illusion that everything is fine and fun once they have done little bit of rote coding. Though hidden in Angular 2 can create confusion for many upcoming days when tight coding might become more biased and undesirably hard to transcribe logically over time.

Why the Hidden Attribute Causes Problems in Angular 2

On the surface, the hidden attribute looks harmless. It is part of standard HTML and simply hides an element from view. The issue is that Angular 2 controls rendering through its own change detection and template system, which does not always align with browser-level visibility rules.

Hidden Bypasses Angular’s Template Control

Angular 2 templates are meant to clearly express intent. Structural directives define whether elements should exist at all, not just whether they are visible. Using the hidden attribute bypasses this mechanism and hands control back to the browser.

This creates two sources of truth. Angular assumes the element exists and should be processed, while the browser simply hides it visually. In code reviews and interviews, this pattern is often flagged as a design smell because it weakens Angular’s declarative approach and makes templates less predictable.

Hidden Only Affects Visibility, Not Component Logic

The hidden attribute only applies a CSS-based visual change. The element remains in the DOM, bindings stay active, and child components continue to run. Lifecycle hooks still fire, subscriptions remain open, and change detection continues as usual.

In Angular 2 applications, this can lead to unnecessary processing and subtle side effects. Developers may assume a hidden component is inactive, when in reality it is still fully participating in the application. This mismatch often makes performance issues and bugs harder to track down.

Better Ways to Control Visibility in Angular 2

Angular 2 includes tools specifically designed to manage visibility in a way that works with its rendering model. These approaches keep UI behaviour tied directly to application state and make templates easier to understand.

Control Visibility in Angular 2

Using Angular-native solutions also improves collaboration. Other developers can quickly see why an element appears or disappears without having to infer behaviour from browser-specific attributes. (Similar principles apply in .NET development.)

Using [class] or [style] Bindings When Needed

In some scenarios, you might find yourself needing a DOM element to remain in place although looking different; Angular provides support for direct binding to CSS classes or styles for things like visibility changes.

This can be helpful for animations, and layout transitions are one of the main benefits. State is still owned by Angular in this case, keeping behaviour quite consistent and easy to test.

Using *ngIf for Conditional Rendering

The *ngIf directive completely adds or removes elements from the DOM based on a condition. When the condition is false, the element does not exist at all. Bindings are destroyed, subscriptions can be cleaned up, and lifecycle hooks stop running.

For most visibility-related cases, *ngIf is the preferred option. It keeps component lifecycles aligned with what users actually see and avoids unnecessary background work. In interviews and practical discussions, favouring *ngIf over hidden is often the expected and recommended answer.