Реагируйте с помощью Typescript. Но должны ли вы?

Сегодня я расскажу вам о своем опыте после перехода моего среднего проекта с JS на TS. Прежде чем мы начнем, есть кое-что, чем я хочу поделиться с вами, ребята. До того, как я реализовал Typescript, мои друзья однажды сказали мне: «Братан, тебе нужно попробовать Typescript». настоящий Java. Теперь я попробовал это, и я никогда не хочу возвращаться, но я не думаю, что я одинок, потому что это была вторая самая любимая технология в опросе stackoverflow 2020 года.

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

Чтобы решить, хотите ли вы использовать Typescript, давайте взглянем на два разных проекта, один с Typescript, а другой без него. Есть много разных способов добавить Typescript в приложение React, в этом случае я использую create-react-app --template typescript для создания приложения реагирования с шаблоном typescript. В документах также есть инструкции по добавлению его в существующий проект и в next.js.

Если мы посмотрим на файловую систему этих двух проектов рядом, наиболее очевидная разница будет заключаться в том, что в проекте TS есть файлы, оканчивающиеся на .tsили .tsxно странно то, что если мы заглянем внутрь одного из этих файлов, код точно такой же, как и в файле JS, и это на самом деле поднимает хороший вопрос. Что такое TS, если мой код точно такой же?

TS как язык является надмножеством JS, что означает, что vanilla JS также на 100% является действительным TS. Другими словами, он просто добавляет дополнительные необязательные функции поверх обычного JS. Связь между scssи cssтакая же, как между TS и JS, и это действительно здорово, потому что означает, что вы не на самом деле не нужно учиться чему-либо, чтобы начать работу с ним. Но вот загвоздка в том, что браузер не умеет запускать машинописный код. Это означает, что нам нужен компилятор, который возьмет наш код TS и скомпилирует его в обычный JS.

В наших проектах TS вы заметите специальный файл с именем tsconfig.json. Он предназначен для настройки поведения компилятора, который сам может взять ваш код TS и конвертируйте его в любой вариант JS, который вы хотите запустить в браузере. Компиляторы действительно крутые, потому что они позволяют вам использовать специальные функции и современный синтаксис JS, не беспокоясь о том, будет ли этот код поддерживаться в старых устаревших браузерах.

Недостатком является то, что теперь у вас есть этот гигантский файл конфигурации, о котором нужно беспокоиться. Обычно все работает нормально, но когда это не работает, вам нужно гуглить все эти разные варианты и выяснять, что они делают. Многие параметры связаны с тем, насколько строг машинописный текст с его правилами проверки типов, и я настоятельно рекомендую сделать его как можно более строгим, установив для параметра strict mode значение true. Поначалу это усложнит написание вашего кода, но в долгосрочной перспективе упростит рефакторинг и сотрудничество с другими разработчиками.

Другим важным параметром является цель, которая является разновидностью JS, и TS тоже скомпилирует ваш код. ES5, версия JS 2009 года, но ваша кодовая база может писать JS 2021 года. Звучит потрясающе, но для этого вам действительно нужен TS. Под капотом JS-версия приложения create-react-app использует компилятор под названием Babel, который делает то же самое, поэтому суть в том, что вы можете писать современный код как в проекте React JS, так и в проекте TS.

Разработчики машинописного текста часто говорят, что это помогает им выявлять глупые ошибки в разработке до того, как они превратятся в огромные бедствия в продакшене. Давайте посмотрим на примере, чтобы понять, правда это или нет.

В проекте JS у меня есть некоторое состояние, которое начинается как пустой объект, теперь где-то еще я могу сослаться на этот объект и попытаться получить доступ к его глубоко вложенному свойству. Это выглядит как правильный код, но когда мы запускаем приложение, мы получаем ошибку cannot read that property.

Такие ошибки постоянно отправляются в производство. Но если мы попытаемся сделать то же самое в TS, это будет похоже на чертову предсказательную программу, которая позволит нам узнать об ошибке еще до того, как приложение запустится.

Я действительно ценю это, потому что я постоянно совершаю такие глупые ошибки. Но имейте в виду, что это не заменяет разработку через тестирование. Он может заранее обнаружить плохо структурированный код, но не может обнаружить плохую логику.

Но теперь давайте рассмотрим самую важную особенность TS. Это система типов и плюсы и минусы ее использования, если мы создаем функциональный компонент. В JS вы заметите, что он имеет тип элемента jsx, кроме того, если мы ссылаемся на реквизиты, они автоматически имеют тип любой. Это довольно расплывчатое определение типа. В целом, в TS мы можем гораздо более четко указать, что на самом деле представляет собой наш код.

React имеет встроенный тип, называемый FC, что означает функциональный компонент, и мы можем назначить этот тип компоненту, используя двоеточие, за которым следует тип, который сообщает компилятору форму этого кода, который выдает ошибку для всего, что не является допустимым. prop и автозаполнение всего остального по умолчанию. Единственная известная реактивная опора — это дочерние элементы, но мы можем определить форму наших собственных свойств с помощью интерфейса TS.

Интерфейс позволяет определить форму объекта путем сопоставления имени свойства с типом. Здесь у нас есть интерфейс с именем CoolProps, который должен быть объектом с двумя свойствами, одним из которых является числоа другой — строка. В текущем виде интерфейс сделает эти свойства обязательными для объекта. Но вы можете сделать необязательным, добавив ? отметьте после имени свойства.