为何使用ng-template而非单纯*ngIf？两种ngIf写法有何选用理由？

Hey there! These are really solid questions that come up a lot when working with Angular templates. Let's break them down one by one.

ng-template isn't a replacement for *ngIf—it's a complementary tool that makes your templates more flexible and maintainable. Here are key reasons to reach for it:

• Reusability: Unlike content wrapped directly in *ngIf, an ng-template defines a reusable snippet you can reference multiple times across your template (or even across components with ngTemplateOutlet). For example, if you need a "no results found" message in three different places, define it once in an ng-template and reference it everywhere instead of duplicating code.
• Cleaner complex logic: When you need more than simple binary conditionals, ng-template pairs seamlessly with directives like ngSwitch or ngTemplateOutlet to handle dynamic template switching. This avoids messy nested *ngIf chains that become hard to read and debug.
• No extra DOM bloat: ng-template itself doesn't render as a real DOM element. If you don't want to wrap conditional content in an extra <div> or <span> (which might break your CSS layout), using ng-template with *ngIf="...; else templateRef" lets you keep your DOM structure lean.
• Clearer separation of concerns: Moving conditional branch content into an ng-template keeps your main template focused on the primary content. Anyone reading your code can immediately see the main flow and then check the linked template for the fallback/alternative content, rather than parsing through a pile of adjacent *ngIf blocks.

This is all about making your logic more intentional, maintainable, and efficient. Here's why the else syntax is often better:

• Explicit mutual exclusivity: The first approach uses two independent *ngIf checks—while logically they're opposites, Angular treats them as separate conditions. The else syntax explicitly tells Angular "this is the only alternative to the main condition," making the logic more robust and eliminating any edge case where both (or neither) might briefly render during state changes.
• Reduced DOM overhead: When show toggles, the first approach destroys one <div> and creates the other. With else, Angular can optimize the switch by reusing the context or minimizing DOM manipulations, which adds up when dealing with complex content or frequent state changes.
• Better readability: The link between the main content and its fallback is immediately clear via the #notShow reference. In the first approach, you have to scan the template to realize the two *ngIf blocks are mutually exclusive—this gets way harder when the content between them is long.
• Easier maintenance: If you ever need to update the condition (say, changing show to show === 'active'), you only have to modify it once in the *ngIf statement. With the first approach, you'd have to update both show and !show checks, which opens the door to typos or inconsistent logic.
• No unnecessary containers: In the first approach, each branch needs a wrapping element (like the <div>) for *ngIf to attach to. With else, the fallback content in ng-template doesn't require an extra container—you can write the content directly inside the template, keeping your DOM structure exactly as you need it.

内容的提问来源于stack exchange，提问作者False Dragon