Основна відмінність між конструктором і в ngOnInitтому, що ngOnInitце гак життєвого циклу і працює за конструктором. Інтерпольований шаблон і вхідні початкові значення компонентів недоступні в конструкторі, але вони доступні в ngOnInit.
Практична різниця полягає в тому, як ngOnInitвпливає на структурування коду. Велика частина коду ініціалізації може бути переміщена ngOnInit- до тих пір , як це не створює умови гонки .
Конструктор антипатерн
Значна кількість коду ініціалізації робить метод конструктора важким для розширення, зчитування та тестування.
Звичайний рецепт відокремлення логіки ініціалізації від конструктора класів - це переміщення її до іншого методу, наприклад init:
class Some {
constructor() {
this.init();
}
init() {...}
}
ngOnInit може виконувати цю мету в компонентах та директивах:
constructor(
public foo: Foo,
/* verbose list of dependencies */
) {
// time-sensitive initialization code
this.bar = foo.getBar();
}
ngOnInit() {
// rest of initialization code
}
Ін'єкційна залежність
Основна роль конструкторів класу в кутовій куті - це введення залежності. Конструктори також використовуються для анотації DI в TypeScript. Практично всі залежності присвоюються як властивості екземпляру класу.
Середній конструктор компонентів / директив вже досить великий, тому що він може мати багаторядковий підпис через залежності, що вводить непотрібну логіку інтіалізації до конструкторського корпусу, що сприяє антипатрітену.
Асинхронна ініціалізація
Конструктор асинхронної ініціалізації часто можна вважати антипатернним і мати запах, оскільки екземпляр класу закінчується до того, як це стане асинхронна рутина, і це може створити умови для перегонів. Якщо це не так, ngOnInitа інші гачки життєвого циклу є кращими місцями для цього, особливо тому, що вони можуть отримати користь від asyncсинтаксису:
constructor(
public foo: Foo,
public errorHandler: ErrorHandler
) {}
async ngOnInit() {
try {
await this.foo.getBar();
await this.foo.getBazThatDependsOnBar();
} catch (err) {
this.errorHandler.handleError(err);
}
}
Якщо існують умови перегонів (включаючи ту, що компонент не повинен з’являтися при помилці ініціалізації), асинхронна процедура ініціалізації повинна відбуватися перед інстанціфікацією компонента та бути перенесена на батьківський компонент, захист роутера тощо
Блок тестування
ngOnInitє більш гнучким, ніж конструктор, і дає певні переваги для тестування одиниць, які детально пояснені у цій відповіді .
Враховуючи те, що ngOnInitпри компіляції компонентів в одиничних тестах не викликається автоматично, методи, які викликаються, ngOnInitможуть бути шпигунними або знущаються після інстанціювання компонентів.
У виняткових випадках ngOnInitможе бути повністю закріплено, щоб забезпечити ізоляцію для інших компонентів (наприклад, певної логіки шаблону).
Спадщина
Дитячі класи можуть лише збільшувати конструктори, а не замінювати їх.
Оскільки thisдо super()цього не можна звернутися , це ставить обмеження на пріоритет ініціалізації.
Враховуючи, що кутовий компонент або директива використовує ngOnInitдля логіки ініціалізації нечутливі до часу, дочірні класи можуть вибирати super.ngOnInit(), викликається чи коли:
ngOnInit() {
this.someMethod();
super.ngOnInit();
}
Це неможливо реалізувати лише з конструктором.
