Коли складні типи шкодять проєкту і як не перестаратися з типізацією?

Система типів TypeScript тюрінг-повна: на рівні типів можна парсити рядки, рахувати й будувати складні перетворення. Це не означає, що так варто робити в коді застосунку.

Ознаки переускладнених типів:

• тип важче зрозуміти, ніж код, який він описує. Новий розробник витрачає годину, щоб зрозуміти, чому помилка компіляції;
• повідомлення про помилки на десятки рядків з вкладеними умовними типами - замість «очікувалося число»;
• редактор гальмує: підказки з'являються з затримкою, tsc працює хвилинами;
• as any поруч зі складним типом - ознака, що тип не впорався з реальністю;
• типи заради типів: рекурсивні утиліти для одного виклику, які можна замінити явним інтерфейсом.

Принципи розумної типізації:

• простіше - краще: явний interface з переліком полів читабельніший за Omit<Pick<A, ...> & Partial<B>, ...>. Дублювання кількох полів інколи дешевше за складну похідну;
• складність - у бібліотеках, простота - у застосунку. Генеріки й умовні типи виправдані в спільних інструментах (клієнт API, будівник форм), які використовуються сотні разів;
• типи на межах, виведення всередині: явно типізувати публічні функції, параметри, повернені значення модулів - а всередині функцій покладатися на виведення;
• дані з зовнішнього світу - схема валідації (Zod), з якої виводиться тип, а не вручну написаний «ідеальний» тип;
• читабельні назви проміжних типів замість одного гігантського виразу.

Продуктивність компілятора (рекомендації з вікі TypeScript):

• інтерфейси замість перетинів (interface A extends B, C замість B & C) - їх відношення кешуються;
• явні типи повернення у великих функціях - компілятору не треба виводити їх щоразу;
• уникати великих об'єднань (сотні варіантів) і глибокої рекурсії в умовних типах;
• tsc --extendedDiagnostics і --generateTrace - знайти, які файли й типи забирають найбільше часу.

TypeScript 7 (нативний компілятор на Go) пришвидшив перевірку в рази, але це не скасовує проблему: складні типи все одно важко читати й підтримувати, а помилки в них - розуміти.

Тест на доречність: чи стане коду помітно безпечніше від цього типу, і чи зрозуміє його колега без вашої допомоги? Якщо на обидва питання відповідь «ні» - простіший тип кращий.

Докладніше в документації: Продуктивність TypeScript