Швидше за все, якщо у вас вже є досвід написання * .ts файлів - ця серія статей буде вам не цікава. Хоча, цю статтю я б порадив прочитати всім без винятку.
Отже, в цій частині серії я відповім на наступні питання:
- Передумови до TypeScript?
- Що з себе являє TypeScript?
- Як влаштований TypeScript?
- Які проблеми вирішує TypeScript?
- У якому випадку слід використовувати TypeScript, а в якому немає?
передумови
Так що ж привело до створення TypeScript? - бажання програмістів менше думати і бути впевненими в завтрашньому дні, а якщо чесно, то:
TypeScript зовні
Також, варто трохи розкрити тему використання сучасних стандартів ECMAScript. Так як TypeScript вимагає компіляції, то чому б не додати можливість використання сучасних стандартів і при компіляції транспіліровать їх в нижчу версію стандартів. В цьому випадку можна привести в приклад всім відомий Babel, який робить все те ж саме. Але порівнювати транспіляцію TypeScript потрібно з Buble, тому що він, на відміну від Babel, на виході має читається, налагоджувати і підтримуваний код. Тобто навіть в тому випадку, якщо ви втратите вихідні, завжди можна працювати зі згенерованих кодом.
Однак, TypeScript вміє знижувати рівень генераторів і ітераторів аж до ES3. Виходить, що ви можете написати код, який використовує Async / Await і скомпілювати його в ES3 - зручно.
TypeScript зсередини
Зсередини TypeScript можна представити у вигляді чотирьох шарів, кожен з яких виконує свою певну роль. В основі, звичайно ж, лежить ядро компілятора, яке включає в себе: парсер, пре-процесор (збирає контексти з .ts і .d.ts файлів), связиватель (пов'язує все декларації), контролер типів (визначає і перевіряє тип кожної конструкції ), емітер (генерує код .js і .d.ts).
TypeScript вирішує
Це та сама частина статті, що допоможе вам самим зрозуміти, чи потрібен вам TypeScript і, як наслідок, подальше читання цієї серії статей. Тут я буду говорити про те, які проблеми може вирішити TypeScript і як він це зробить. Я постараюся обійтися без очевидних прикладів, на кшталт того, що компілятор не дасть вам скласти число і рядок, якщо ви вкажете типи змінних. Також, я не став заглиблюватися в ООП, тому що одними лише abstract class. class extends class, class. class implements class і private. public. static в TypeScript не заманиш. Але, звичайно ж, про все це я буду розповідати в наступних частинах серії.
підтримуваний код
Якщо ви опишете ваш код типами, то підтримувати цей код стане набагато простіше - особливо, з огляду на надану функціональність інструментарію TypeScript.
Мабуть, тут я приведу нетиповий для такого роду статей приклад, де у нас є функція, що приймає якийсь об'єкт, що містить деяку кількість властивостей, причому деякі з них можуть бути необов'язковими.
Які проблеми я бачу в цьому коді:
Час майбутніх розробників можна було б заощадити, використовуючи TypeScript:
Спробуємо чесно поглянути на цей код і виділити його сильні і слабкі сторони. До плюсів можна віднести:
На жаль, потрібно розповісти і про одне мінусі: ви не можете вказати значення за замовчуванням в інтерфейсі, як це зроблено в JSDoc. Біда чи це?
Можливо, читача розсмішить той факт, що приклад наводиться на невеликій функції, яка вміщується в п'ять рядків. Однак не варто забувати, що в реальних проектах і, особливо в корпоративному середовищі, таких функцій меншість. Так-так, відповідальність, рефакторинг і інше - десь хтось не додивився при рев'ю коду, десь потрібно було ASAP, тому що все горить і інші відмазки, які призводять до того, що розробник повинен витрачати свій час на пошук варіантів використання якоїсь функції.
чистий код
Ваш код стає чистішим, як мінімум через те, що ви можете пропускати конструкції виду:
Ця перевірка вам просто не потрібна, тому що TypeScript не дасть скомпілювати коду, де в цю функцію передається щось відмінне від масиву. Причому, ви можете вказати тип елементів масиву і тип того, що повинна повернути функція - це допоможе вам вирішити проблему неправильного використання функцій навіть до того, як ви захочете написати на неї тести.
Знову-таки повторюся, що це не аргумент для тих, хто пише якусь бібліотеку, яка використовується як JS-модуль поза TypeScript-оточення. В цьому випадку вам все одно доведеться писати такі перевірки, якщо ви хочете убезпечити користувача.
Рефакторинг без наслідків
Як би це смішно звучить, але рефакторинг в великому проекті - штука складна. Особливо в тому випадку, якщо в проекті тести написані не на кожну функцію або написані так, що покривають не всю кодову базу або не всі випадки використання. Навіть трохи змінюючи поведінку функції ви завжди ризикуєте повернути з неї або передати (забути передати) в неї щось не те. Цей випадок більше в скарбничку тестів, але все таки з TypeScript ви можете бути впевнені, що функція повертає той тип, що ви вказали і приймає саме те, що ви вказали.
Актуальна документація
З TypeScript ви вільні не писати в повній мірі документацію перед функцією, наприклад, використовуючи JSDoc. Чому в повній мірі? - тому що написати в двох словах що ж робить ваша функція все таки потрібно. Також, доведеться описати властивості інтерфейсу або параметри функції, якщо їх імена не дають повного уявлення про своє призначення.
Сучасні можливості і стандарти
Трохи гучну заяву, але знайте, що в деяких випадках TypeScript допомагає V8 оптимізувати ваш код. JIT в V8 виробляє деоптімізацію конструкцій, якщо передане в неї значення змінюється кілька разів поспіль. Відповідно, якщо ви пишете добре збірний код, то передати щось відмінне від дозволеного значення просто неможливо - буде дотримуватися принцип єдності переданого типу і деоптімізаціі не буде. Особливо це відноситься до функцій, які приймають на вхід об'єкти.
За та проти
Тепер, коли ви знаєте про те, що ж із себе представляє TypeScript, я спробую сказати в яких випадках потрібно і не потрібно його використовувати.
Мої доводи дуже прості: TypeScript потрібно використовувати завжди, якщо ви знаєте, що проект буде рости і його потрібно буде підтримувати. Перекладати чи вже написані проекти? - точної відповіді я вам дати не можу, звичайно в таких проектах складно викроїти час на рефакторинг і вже тим більше на перехід на TypeScript. Однак, все ж варто подумати над цим, адже ви отримуєте типізацію і можливість використання сучасних стандартів.
У цій статті я спробував розповісти вам, що з себе представляє TypeScript і які проблеми він вирішує. Однак, ви можете не погодитися з моїми доводами, тому що динамічна типізація завжди вабить більше, ніж статична. Саме тому я залишу тут список статей, які дозволять розглянути TypeScript з інших сторін.
оновлення
Ділимося на оплату хостингу або кави.
Чим частіше п'ю каву, тим частіше пишу статті.