Существует ряд онлайн-форумов, на которых разработчики Angular всегда были озадачены различиями, возникающими в их приложении, когда они меняют любое условие с ngShow на ngIf. Вот некоторые типичные проблемы, с которыми люди сталкиваются с ngIf -
https://github.com/vaadin/vaadin-grid/issues/411
https://github.com/angular/angular/issues /6179
Чтобы найти решение этой проблемы, нам сначала нужно понять разницу между их использованием. Использование условий ngShow или скрытия удерживает элемент в DOM при переключении CSS элемента с предоставленного стиля, когда условие показа истинно, на отображать: нет, когда условие скрытия становится истинным, и наоборот. В то время как *ngIf, с другой стороны, создает элемент в DOM только тогда, когда предоставленное условие if становится истинным. Поэтому всегда лучше, а иногда даже необходимо работать с *ngIf, особенно если общий компонент используется несколько раз в одном модуле, и мы хотим, чтобы в DOM одновременно присутствовал только один экземпляр этого компонента. Итак, я столкнулся с аналогичной проблемой с моим компонентом Drag Drop на портале ADM и Auth, где использовались несколько модальных компонентов Drag Drop и использовались только modal.show() или modal.hide() для отображения или скрытия модального окна. Это сохраняло несколько компонентов перетаскивания в DOM, которые мешали друг другу и, следовательно, должны были быть обернуты вокруг * ngIf, что гарантировало бы, что только один модальный компонент перетаскивания будет присутствовать в DOM одновременно. Но тогда использование *ngIf означало, что когда я хочу использовать компонент перетаскивания, цикл текущих событий или цикл цикла углового дайджеста будут создавать только элемент в DOM, а идентификатор компонента будет не определен, поскольку собственный элемент не был доступны в DOM во время выполнения этого цикла. Такое поведение означало, что открытие модального окна сделало бы его непригодным для использования в этот момент, и его можно было бы использовать только в следующем цикле событий. Чтобы решить эту проблему, мы можем использовать любые методы javascript с обратными вызовами, чтобы они инициировали следующий цикл обработки событий и обеспечивали нашу функциональность. Вот решение, использующее setTimeout с параметром 0-time.
HTML-код

<button (click)="openModal()">Open Modal</button>
<div class="modal fade" #sampleModal *ngIf="showModal()">
     <!--Modal View Goes Here-->
</div>

Код TypeScript

//Inside export component class
showModal:boolean = false;

openModal = function () {
        this.showModal = true;
        var that = this;
        setTimeout(() => {that.showHideModal('sampleModal', 'show')  }, 0)
}

showHideModal(id, showOrHide) {
        $(this[id].nativeElement).modal(showOrHide);
}

Здесь происходит следующее: когда я нажимаю кнопку, чтобы открыть модальное окно, оно запускает событие щелчка и вызывает функцию openModal, которая устанавливает для условия ngIf значение true. Теперь мы используем функцию showHideModal, передав модальный идентификатор, но элемент был создан в текущем цикле событий, который был вызван событием щелчка, и поэтому нам нужно открыть модальное окно, используя его идентификатор в следующем цикле, поскольку this[id] undefined в текущем цикле. Итак, во-первых, мне нужно передать текущий контекст для открытия модального окна в следующем цикле, и поэтому я устанавливаю переменную that как this. И теперь я вызываю функцию showHideModal как обратный вызов, используя setTimeout с 0 мс в качестве параметра. Таким образом, к тому времени, когда вызывается функция, представленная в setTimeout, которая является следующим циклом, this[id] становится доступным, и, таким образом, мы можем использовать модальное окно now, которое работает, как и ожидалось.

Таким образом, хорошее понимание цикла событий и подъема JS имеет большое значение для решения множества «неопределенных» ошибок и проблем, возникающих в JS и основанных на JS фреймворках и библиотеках.