Чому TypeScript - найкращий спосіб написати Front-end у 2019 році

І чому ви повинні переконати всіх використовувати його.

TypeScript стає все більш популярним у середовищі Front-end. Вже 80% розробників визнають, що хотіли б використовувати або вивчати TypeScript у своєму наступному проекті. Сам я полюбив це, оскільки вперше використав його. І я продовжую використовувати це у всіх своїх наступних проектах точно.

Деякі люди висловлюють занепокоєння з приводу того, що TypeScript є непотрібною залежністю переднього ланцюжка інструментів. Є це? Слідкуйте за мною, щоб дізнатися, що реальність зовсім протилежна.

Історія про "хлопця, що динамічно набирається"

Протягом більшості 18 років моєї кар’єри програмування я ніколи не любив мови, які були статично введені. Оскільки я розпочав програмування у 2001 році, мої мови вибору завжди динамічно набиралися: PHP, JS, Ruby, Elixir. Я робив кілька програм на C ++ та Java тут і там, але завжди ненавидів ці середовища. ("Чому мені потрібно передавати тип скрізь? Це відстійно. Я можу сам про них подбати".)

Все змінилося приблизно 2 роки тому. Це було коли я вперше використовував TypeScript. Однак я не закохався в неї з самого початку. У перші дні мене це насправді дратувало. Однак ситуація швидко змінилася. Чим більше визначень типів я вкладав у код, тим частіше я помічав, що це рятує мене від того, щоб витрачати час на вручну налагодження дурних помилок у консолі. Я починав цінувати типи.

У наступні два роки, коли я співпрацював над фронтальними програмами, будь то Angular або React, я помітив, що незалежно від того, якою рамкою я користувався, завжди було це одне, що я пропустив у всіх проектах .js: TypeScript .

Тепер я мушу визнати. Я більше не люблю динамічно набрані мови. Я все ще можу дуже ефективно працювати над ними, але це робить мене нещасним, коли я не можу просто знайти визначення типів у IDE або довіряти компілятору під час прототипування коду. (Єдине, що я все ще сумую в Еліксирі - це сильні типи.)

На щастя, нам не потрібно чекати, поки комітет Ecma TC39 введе систему статичного типу в JavaScript. Ми можемо використовувати TypeScript замість цього. Особливо в нових проектах, коли клопоту з його використання мінімально.

Аргументи анти-TypeScript

Тим не менш, деякі все ще наважуються стверджувати, що залучення TypeScript до вашого проекту:

  • збільшити тривалість роботи нових розробників на борту,
  • складне обслуговування,
  • ввести багато конфліктів з React,
  • збільшити час розробки,
  • підключити проект до деяких технологій хіпстерію, які не існуватимуть через рік,
  • не допускати вербування хороших людей з JS,
  • унеможливити приведення коду з баз коду, що не належить до ТС,
  • ускладнюють редагування програми у віддаленому майбутньому.

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

Саме тому я вирішив написати цю статтю. Можливо, це допоможе переконати вас, ваших друзів, товаришів по службі, або вашого CTO, у цій приголомшливій мові.

Примітка. У цій статті я не пояснюватиму, що таке TypeScript. Я зосередитимусь лише на тому, "чому" ви повинні ним користуватися. Якщо ви все ще не знайомі з тим, що насправді є TypeScript, пропоную вам спочатку прочитати декілька наступних посилань:

  • "Що таке TypeScript і чому я використовую його замість JavaScript?" - Bogaards, Lodewijk, StackOverflow
  • Офіційний веб-сайт мови TypeScript
  • "TypeScript - JavaScript з наддержавами" - Індрек Ласн, Середній
  • “TypeScript Deep Dive” - електронна книга Басарата Алі Саеда

Переваги TypeScript

1. Код легше зрозуміти

Зазвичай, коли ви працюєте над фрагментом коду, наприклад, кодом функції, для повного його розуміння потрібно зрозуміти:

  1. Які аргументи він приймає?
  2. Яке значення воно повертає?
  3. Які зовнішні дані йому потрібні?
  4. Що це робиться з цими аргументами та зовнішніми даними, щоб отримати повернене значення?

У динамічно набраних мовах дуже часто важко відповісти на перші три питання. Якщо функція отримує аргумент статті, що це саме? Це об’єкт з деякими атрибутами статті? Які точні атрибути існують? Чи є article.title чи article.name? Чи можу я завжди припускати, що Article.title існує? Як щодо статті.isPublished? Я, можливо, знаю, що цей атрибут об'єднується в об’єкт статті в більшості місць програми, але чи можу бути впевнений, що він завжди присутній і в цьому місці?

Щоб відповісти на всі ці запитання, зазвичай потрібно виконати одне з наступних дій:

а) поставте console.log (article), запустіть скрипт у своєму браузері (можливо, трохи натисніть на інтерфейс користувача) та прочитайте журнал;

б) подивіться, де використовується функція, і звідти відстежте, які дані вводяться у всі її виникнення;

в) запитайте свого колегу, що нещодавно працював над цим кодом (сподіваючись, що вони ще живі, в Інтернеті, і пам’ятайте про цей код);

г) припустимо, що стаття є такою, як ви думаєте, що є, і просто сподівайтеся, що вона працює.

Це вам звучить знайомо?

Мені це здається типовим робочим процесом веб-розробників на будь-якій динамічно набраній мові, як JS, PHP, Ruby, Python, Elixir.

Статично типізованими мовами, такими як TypeScript, ви отримуєте відповіді на всі вищезазначені питання негайно від свого IDE та компілятора. Більше не потрібно переглядати всю базу коду, тримати клопоти своїх однокласників питаннями або ризикувати виникнення помилок на виробництві.

2. Код простіший і швидший в реалізації

Зазвичай, коли вам потрібно створити нову функцію або новий компонент, ваш робочий процес, ймовірно, виглядає приблизно так:

  1. Завантажте компонентну функцію, складіть її конструкторські аргументи, напишіть код, що залишився.
  2. Якщо для нього потрібні будь-які зовнішні або складні дані (наприклад, користувач чи статті), здогадайтесь, як вони будуть виглядати, збережіть їх у власній пам'яті та використовуйте їх у коді.
  3. Помістіть компонент у свою програму та передайте реквізит у нього.
  4. Тестуйте його вручну або за допомогою одиничних тестів. (Вам потрібно переконатися, що він отримує реквізит, який у нього повинен бути, і що він працює як слід.)
  5. Якщо щось не вірно, поверніться до свого коду, спробуйте з’ясувати, що з цим не так, виправте це та поверніться до кроку "ні". 4.

У TypeScript це схоже, але простіше та швидше:

  1. Завантажте компонентну функцію, визначте її тип типу та реалізуйте її.
  2. Якщо для цього потрібні будь-які зовнішні або складні дані, знайдіть їхні інтерфейси та повторно використовуйте їх (повністю або частково).
  3. Помістіть компонент у свою програму та передайте реквізит у нього.
  4. Це воно. (Якщо ви правильно підібрали набори типів між викликом і позивачем, все повинно працювати бездоганно. Єдине, що вам доведеться перевірити зараз, - це фактична бізнес-логіка вашого компонента.)

Таким чином, кожного разу, коли ви пишете код у TypeScript, він не тільки читає і менш схильний до помилок, але, головним чином, просто простіше міркувати.

3. Код простіший для рефактора

Часто ви хочете дуже багато речей, які вам хотілося б переробити, але оскільки вони торкаються стількох речей і файлів, ви просто занадто боїтесь їх змінювати.

У TypeScript такі речі часто можуть бути відновлені лише одним клацанням команди «Перейменувати символ» у вашому IDE.

Перейменування програми

У динамічно набраних мовах найкраще, що ви можете отримати, щоб допомогти вам переробляти декілька файлів одночасно, це пошук і заміна на RegExp.

Шукати та замінювати вже не потрібно. За допомогою команд IDE, як «Знайти всі виникнення» та «Перейменувати символ», ви можете побачити всі події в додатку заданої функції, класу чи властивості об’єктного інтерфейсу.

Щоразу, коли ви хочете трохи вдосконалити систему складання, перейменувати компоненти, змінити об’єкт користувача або видалити застарілий атрибут, вам більше не потрібно боятися порушувати речі. TypeScript допоможе вам знайти всі звички відновленого біта, перейменувати його та попередити про помилку компіляції, якщо ваш код має будь-які невідповідності типу після рефактора.

4. Менше клопів

Протягом багатьох років передового веб-розробки я помітив, що можу заощадити приблизно ~ 50% свого часу на виправлення помилок, просто сидячи поруч зі мною, хто одразу кричить на мене, коли я робив друк, використовуючи значення, яке може бути нульовим, або передаючи об'єкт в місце, де він повинен бути масивом.

Я радий сказати, що нарешті зустрів цього приятеля: його називають TypeScript.

Завдяки їй зараз важче написати недійсний код. Якщо вона компілюється, ви можете бути абсолютно впевнені, що вона насправді працює.

5. Менше випробувань на котлах

Якщо ви впевнені, що ваші змінні правильно передані у всі задані місця, вам більше не потрібно тестувати все це.

Замість того, щоб писати прості тестові модулі та інтеграційні тести, ви можете більше зосередитися на тестуванні бізнес-логіки вашого додатку, а не на те, чи правильно передаються ваші аргументи функцій між собою.

Менше тестів означає коротший час для розробки нових функцій та меншу базу коду, яка, в свою чергу, є менш складною, менш схильною до помилок і простішою в обслуговуванні.

6. Код легше об'єднати

Новий молодший розробник у вашій команді щойно випустив PR, вводячи новий код. З першого погляду все виглядає нормально: код виглядає добре, одиничні тести є, все проходить зеленим кольором.

Чи можете ви бути впевнені в цей момент, що він працює? Що робити, якщо у нього немає належних тестових одиниць? (Так. Давайте познайомимося з людьми реальності, багато хто з них все ще не пише їх достатньої кількості.) Ви просто довіритесь творцю PR? Або ви зосереджите свої дорогоцінні 5 хв, щоб насправді запустити код і протестувати його?

Якщо у вашій ланцюзі інструментів є TypeScript, це дає вам ще одну перевірку впевненості: перевірку компіляції typedef.

Якщо код виглядає добре, одиничні тести є, і вся справа складається, то ви можете бути впевнені, що вся справа працює.

TypeScript полегшує довіру іншим розробникам. Це може покращити темп, з яким ви переглядаєте та об’єднуєте PR.

(Те ж саме йде в інший спосіб: завдяки визначенням типів, для нових розробників легше зрозуміти, чим насправді діють коди інших людей, не потребуючи глибокого занурення в нього чи запуску його самостійно.)

7. Допомагає розробнику в правильному робочому процесі

Коли ви пишете код на мовах статичного типу, спочатку потрібно подумати про типи даних, які ви отримаєте, а потім про тип даних, які ви хочете створити. Зазвичай лише після цього ви сідаєте на фактичну реалізацію.

Багато людей будуть ставити своє життя на те, що це правильний процес кодування.

Наприклад, щоразу, коли ви розробляєте алгоритм, слід спочатку продумати його теоретичну формулу, а потім реалізувати його.

Або щоразу, коли ви робите TDD, спочатку потрібно подумати, як ваш код буде працювати насправді (які дані він отримає та які дані буде виробляти), записати його як тести, а потім реалізувати власне код.

Те саме стосується і TypeScript. Це спонукає вас подумати про інтерфейс свого коду, перш ніж сісти за його внутрішню реалізацію.

Проблеми типу TypeScript

1. «Це зашкодить набору персоналу»

Буде?

Регулярні опитування JS чітко показують, що все більше людей обидва програмують на TS або бажають спробувати.

https://2018.stateofjs.com/javascript-flavors/typescript/

Наведене вище опитування доводить це: станом на 2018 рік 80% розробників, які бажають працювати в TypeScript.

Наявність TypeScript у вашому стеку, ймовірно, не зашкодить вашому набору. Насправді це може зробити навпаки. Якщо розробник побачить, що ви використовуєте найкращі інструменти, доступні на ринку, він буде більш охочим працювати у вашій компанії. Сучасні інструменти приносять сучасні розробники.

2. "На борту борту знадобиться більше часу"

Правда полягає в тому, що хоча TypeScript - це набір JavaScript, це щось нове, чому кожен повинен вивчити. Розробник, незнайомий з TS, повинен буде прочитати про нього принаймні годину-дві, перш ніж почати співпрацювати над таким проектом.

Навпаки, якщо у вас вже є вбудований проект у TypeScript, для нових розробників буде дуже легко вписатись. Синтаксис TS - це інтуїтивно зрозумілий і дуже простий для розуміння (що, мабуть, є причиною того, що він набув такої популярності). Загальні інтерфейсні функції, типові захисні пристрої, умовні типи? Вам ніколи не доведеться чіпати і не розуміти їх у 99% щоденної роботи. Решта 1% - це зазвичай те, що потрібно зробити лише на початку, що може підготувати вже вільний програміст ТС.

Крім того, завдяки перевагам TS (про які я вже згадував раніше) новому розробнику буде легше почати робити справи у вашій існуючій кодовій базі. Якщо йому потрібно лише змінити дрібницю або реалізувати щось нове, йому більше не потрібно переглядати всю кодову базу, щоб зрозуміти, які дані передаються і куди. Він може миттєво його прочитати у своїй IDE і пограти з даними. Компілятор TS дасть йому миттєвий відгук про використовувані ним змінні та керуватиме ним, коли він робить будь-яку помилку.

3. "React / Redux і TS не підходять один одному"

Компонент кнопки в React і TypeScript

Помилковий. TS вже давно підтримує TSX. Також завдяки таким простим загальним типам, як React.Component , ви можете позбутися від PropTypes і використовувати натомість систему реального типу.

Це правда, що близько року тому потрібно було написати трохи кодового шаблону, щоб змусити TypeScript працювати з творцями дій Redux. Але оскільки TS 2.8 вийшов у лютому 2018 року, це вже не так. У TypeScript ви можете мати як набраний, так і простий код React / Redux. FYI, React Contexts або Hooks бездоганно працюють з TypeScript.

4. "Неможливо повторно використовувати JS-код у додатку TS"

Знову ж, помилково. Будь-який код JS є дійсним кодом TS.

Це правда, що якщо ви використовуєте TS у суворому режимі (noImplicitAny), вам доведеться додавати тут і там деякі типи, щоб JS-код працював. Але це все! Існує навіть плагін IDE, який може автоматично перетворювати ваші компоненти JS React безпосередньо в TS.

Коли вам потрібно скопіювати якийсь дивний старий постачальник js lib у ваш проект TS: просто зробіть це. Якщо для нього немає типізацій TS (що трапляється все рідше і зараз), додайте їх самостійно або просто використовуйте будь-який при посиланні на постачальника. Це не так, як раптом ви втратите безпеку типу в усьому додатку. Ви втратите його лише в шарі, який торкається нетипізованого постачальника. Але це не заважає легко вводити шар принаймні. А для постачальника ви завжди можете додати його типи згодом, щоразу, коли вирішите, що вони також будуть корисними.

5. "Вибираючи TypeScript, ми можемо в кінцевому підсумку заблокувати якийсь застарілий інструмент, який ніхто не підтримуватиме в майбутньому"

На даний момент TypeScript використовується Microsoft, Asana, Lyft, Slack, усіма розробниками Angular 2+, декількома розробниками React & Vue.js та тисячами інших компаній. Багато інших приєднується до них щодня. На даний момент TypeScript - найпопулярніший суперсет JS, і він скоро не знижується.

Який шанс відмовитися від такої мови?

Я б сказав, що близький до нуля. Єдиний сценарій, коли ТС міг би померти, це якби JS самостійно вводив типи на свою мову. Але це точно не відбудеться незабаром точно. Принаймні, не в наступні ~ 5–10 років. У рідкісному випадку, який насправді трапиться, ви можете бути впевнені, що також знайдуться інструменти, які дозволять вам легко перейти з ТС на набраний JS.

~ 5–10 років відтепер може бути часом, коли ніхто більше не знає Реагувати, Вує чи Кутовий. Але ви не бачите проблем із дотриманням тих кадрів, напевно? ;)

6. "Що з потоком?"

TypeScript дає вам те саме, що робить Flow та багато іншого. Він також є більш популярним.

Завантаження TS проти потоку в хвилину за останні 2 роки (npmtrends.com)

Просто цього має бути вже достатньо, щоб Ви взагалі не враховували Flow. Якщо це те саме, але з меншою функціональністю та значно меншою підтримкою громади, чому б ви це вважали?

Заднім поглядом Flow був настільки ж популярний, як і TS близько 3 років тому, коли вони обидва були новими гравцями на ринку. Одного з них підштовхували спільноти Microsoft та Angular, а іншого віддавали перевагу Facebook та частина спільноти React.

TypeScript зрештою переміг. В даний час все більше розробників з усіх фронтальних фреймворків переходять на TypeScript.

Там також є кілька інших набраних альтернатив JS (наприклад, PureScript або Elm), але давайте їх тут не розглядати. Я хочу поговорити про те, що має широку підтримку громади та кілька компаній, які вже використовують це у виробництві, а не лише про декількох любителів. (Вибачте, люди.)

Мінуси TypeScript

1. Потрібен крок компіляції

Деякі з моїх бек-енд-друзів Node.js сказали мені, що вводити TS для них просто не варто, оскільки це принесе багато клопоту з необхідністю попереднього компілювання всіх .ts-файлів, перш ніж запускати їх у Node.

Хоча, напевно, ви можете впоратися з хорошою установкою і розробкою, але я не можу погодитися, що це додасть трохи накладних витрат до вашої програми Node.js.

Я не можу погодитися з цим у середовищі Front-end. В даний час всі складають JS на передовій. Вам потрібна підтримка застарілого браузера? Особливості ES7? CSS-в-JS? Для всього цього ви, мабуть, вже використовуєте бабель TypeScript можна компілювати з Babel, як і будь-який інший синтаксис JS (включаючи ES7 або JSX).

Приведення TypeScript до вашого переднього проекту майже не накладає накладних витрат на налаштування збірки. (Це може призвести до накладних витрат лише у випадках, коли ви зовсім не компілюєте свій JS, але це трапляється на передній частині дуже рідко.)

2. Трохи складно налаштувати

Я можу погодитися з цим. Наприклад, яка різниця між додатком Next.js та додатком Next.js у TypeScript? У другому випадку вам потрібно змусити ваш сервер Node.js, вебпакет і тестовий бігун для роботи з TypeScript. Крім того, кожного разу, коли ви додаєте бібліотеку на зразок React, Redux, Styled-Components, вам також потрібно додати для неї typedefs, наприклад, npm i @ types / styled-компоненти (якщо тільки в lib не входить файл TS typedefs).

Питання, на яке вам потрібно відповісти, але як часто ви робите таку справу? Чи так багато зусиль, щоб бути гідним відмовитися від усіх переваг TypeScript?

Підсумок

Я кажу, що всі ми повинні раптом перейти на TypeScript? Ні. Наприклад, перехід на нього в існуючому проекті, безумовно, є великою роботою, і перед цим слід серйозно продумати.

Однак якщо ви створюєте нову програму, яка потребує постійного обслуговування, справа буде зрозумілою. Перейдіть з TypeScript. Чесно кажучи, я хочу почути, які причини проти використання TS у будь-якому з ваших наступних передових проектів.

Я просто хочу сказати це: використовуючи TypeScript, ви отримуєте безліч вагомих переваг, затрати на невеликі додаткові зусилля на початку.

Зробимо TypeScript люди fol

Посилання

Про TypeScript

  • "Що таке TypeScript і чому я використовую його замість JavaScript?" - Bogaards, Lodewijk, StackOverflow

«Перехід на TS» Case Studios

  • "TypeScript на Lyft" - Мохсен Азімі, Середній
  • "TypeScript на слабій" - Фелікс Різеберг, Середній
  • "Як ми перенесли проект 200K + LOC на TypeScript і вижили, щоб розповісти історію" - Клео Петров, Hashnode
  • "Перетворення рядків 600K в TypeScript за 72 години" - Пол Дрейпер та Райан Стрінгем, LucidChard TechBlog

Інші відгуки про TS

  • «7 поганих причин не використовувати TypeScript» - Дмитро Пашкевич, заг
  • «Навіщо використовувати TypeScript, хороші та погані причини» - Charly Poly, Medium
  • "JavaScript проти TypeScript проти ReasonML" - д-р Аксель Раушмайер, 2ality
  • “Машинопис - навіщо його використовувати?” - Медід, Середній
  • "Чому TypeScript стає все популярнішим" - Мері Бренскомб, The New Stack