Какие знаешь жизненные циклы компонента в Angular

А, ну вот, жизненные циклы компонентов в Angular, ёпта! Сидишь такой, пишешь компонент, а он тебе как живой организм — рождается, взрослеет, меняется и, в конце концов, накрывается медным тазом. Пиздец, целая драма в отдельно взятой TypeScript-классе.

Смотри, чтобы не облажаться, нужно знать, в каком порядке эти хуки вызываются. Их там, блядь, овердохуища, но основные, которые реально нужны, — это несколько.

Вот они, по порядку, как в хорошем борделе:

1. ngOnChanges — это когда тебе в компонент через @Input() что-то прилетает снаружи. Родительский компонент такой: «На, сынок, держи пропс!». И вот этот хук срабатывает КАЖДЫЙ РАЗ, когда эти пропсы меняются. Первым делом, ещё до инициализации.

2. ngOnInit — а вот это святое, блядь! Вызывается один разок, сразу после первого ngOnChanges. Тут ты обычно все свои начальные дела делаешь: данные с сервера тянешь, подписки какие-то инициализируешь. Место для стартовой логики, а не для того, чтобы в конструкторе весь огород городить.

3. ngDoCheck — о, этот хитрый жук! Вызывается при КАЖДОМ цикле обнаружения изменений. Часто-часто, как сердцебиение. Тут можно свою кастомную логику проверки впихнуть, если стандартный механизм Angular — хуй собачий для твоих нужд. Но юзай осторожно, а то производительность в пизду улетит.

4. ngAfterContentInit — срабатывает один раз, после того как весь контент, который тебе впихнули через <ng-content> (этот самый проекционный слот, блядь), проинициализируется.

5. ngAfterContentChecked — а этот вызывается после КАЖДОЙ проверки того самого спроецированного контента. Опять же, может быть часто.

6. ngAfterViewInit — важный момент! Вызывается один раз, когда инициализируются ВСЕ дочерние компоненты и директивы, а также сам шаблон текущего компонента. Вот тут, например, можно безопасно обращаться к ViewChild — они уже будут готовы.

7. ngAfterViewChecked — и снова проверка, но уже всей вьюхи. После каждого цикла детекта. Опять предупреждение: не накосячь тут с тяжелыми операциями, а то приложение захлебнётся.

8. ngOnDestroy — финал, блядь, трагический! Вызывается прямо перед тем, как компонент отправят на свалку истории. Тут ОБЯЗАТЕЛЬНО надо отписаться от всех Observable, остановить таймеры, убрать слушатели событий — в общем, прибраться за собой. Иначе будут утечки памяти, и приложение будет жрать оперативку, как свинья.

Вот тебе пример, как это выглядит в коде, без всяких там изысков:

export class MyComponent implements OnInit, OnDestroy {
  ngOnInit() {
    console.log('Component initialized');
  }

  ngOnDestroy() {
    console.log('Component destroyed');
  }
}

Вот и вся философия. Запомни эту цепочку, и будешь как бог в своём компоненте — всё контролировать и нигде не налажать. Главное — не путай AfterContent с AfterView, а то будет чих-пых тебе в сраку от неожиданных багов.