TypeScript или JavaScript: что приоритетнее?​

Есть много адептов и хейтеров TypeScript, в этом вопросе всё не так однозначно, просто выскажу своё мнение.

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

Для меня TypeScript решает множество проблем, я его невероятно люблю и стараюсь погружаться в него всё глубже, а всё потому что разработка с ним для меня становится в разы более приятным занятием, чем без него. Код на TypeScript более читаемый, в него можно быстрее погрузиться и внести изменения, а приложения, написанные на нём, потенциально ловят гораздо меньше багов.

Также очень нравятся дополнительные типизируемые сущности в языке в лице типов и интерфейсов. Они позволяют понять что делает тот или иной код, порой, даже без чтения самого кода. Мы можем взглянуть на интерфейсы ввода/вывода данных и примерно понять что происходит в конкретной функции, что упростит её чтение и понимание в дальнейшем, если остается такая необходимость. То есть типы, помимо очевидной пользы в плане стабильности кода, несут и дополнительную функцию — документация кода.

Но у TypeScript есть и недостатки. Для меня главным недостатком является то, что компилятор TypeScript может быть неоптимален. Команда разработчиков старается быстро править все нюансы, но пару раз точно я ловил кейсы, где проблема производительности решалась изменением расширения файла на .js, а значит, что никто не защищен от подобных казусов.

Мой вывод заключается в том, что если TypeScript и ужасен, как об этом некоторые говорят, то чистый JavaScript для меня ещё страшнее. Я себя, по крайней мере на данный момент, больше отношу к адептам TS, нежели к его противникам.

Если говорить с точки зрения рынка, то современную фронтенд разработку без TypeScript мне представить не получается. За последние годы, навык разработчиков «Знание TypeScript» перешёл из категории «Желательно» в категорию «Обязательно» и очень плотно там закрепился. Прогнозов на обратный процесс пока точно не будет. Есть ощущение, что TypeScript с нами на очень долго.

Поэтому если вы хотите быть максимально конкурентноспособным на рынке, то стоит признать, что TypeScript — стандарт. Если вы начинающий разработчик, то придётся смириться с тем, что TypeScript придётся выучить.

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

#web #typescript #javascript

Комплексные состояния

Есть такой код:

const [userData, setUserData] = React.useState<IData>({
  identifier: "",
  password: "",
});

Как его можно исправить:

const [identifier, setIdentifier] = useState<string>("");
const [password, setPassword] = useState<string>("");

Почему я считаю что так лучше:
1. Проще следить за иммутабельностью состояния, так как не нужно постоянно разворачивать prev объект
2. Легче контролировать зависимости и сайд эффекты, если на состояние завязывается, например, useEffect
3. Визуально в использовании считается легче
4. useState вместо React.useState, ИМХО приятнее
5. Нет необходимости создавать ещё какой-то тип

В целом, можно и так оставить то. Работать будет, и даже уже сейчас работает. Но лично мне такое бьет по глазам.

@prog_way_blog —#typescript #web #review

Лучшие практики типизации

В рамках ведения проектов и код-ревью я частенько натыкаюсь на странности написания TypeScript кода. В этом посте я постарался собрать самые частые ошибки, на которые точно стоит обратить внимание.

1. Лишний контекст

// плохо
type Person = {
 personName: string;
 personAge: string;
}

// замечательно
type Person = {
 name: string;
 age: string;
}

2. enum везде. Даже там, где не нужно.

Сила enum заключается в том, что помимо перечисления внутри контекста, enum можно использовать в качестве типа. Если вы не планируете использовать перечисления как тип, а лишь маппите что-либо в рамках одной сущности, то используйте константные объекты:

const Status = {
 Success: 'success',
 Fail: 'fail'
} as const;

Проблема использования enum гораздо глубже, чем может показаться на первый взгляд. Думаю, что ей можно посвятить отдельный пост.

3. Злоупотребление any. Я не противник использования any в случаях, где это действительно необходимо, но многие, даже высокого грейда разработчики, не понимают зачем конкретно он нужен. Прежде, чем воткнуть any, пожалуйста, попробуйте использовать unknown. Это сделает ваш код гораздо безопаснее.

4. Использование Definite Assertion оператора. Это когда вы утверждаете оператором восклицательного знака !, что значение точно есть, хотя оно может быть и undefined:

// так делать не нужно, лучше добавить дополнительное условие
const foo = (arg?: string) => parseInt(arg!)

5. Злоупотребление оператором as. Ровно та же проблема, что с any. Самый частый пример, что мне доводилось видеть:

type Person = {
 name: string
}

// плохо
const person = {
 name: "Denis"
} as Person

// замечательно
const person: Person = {
 name: "Denis"
}

6. Отдельным и крайне важным для меня пунктом выделю оформление enum. Согласно всем стайл-гайдам мира, enum — сущность, группа, в единственном числе, оформленная определенным образом.

// плохо
enum OPERATION_STATUS {}
enum STATUSES {}
enum STATUS {}
enum HTTPStatus {}

// замечательно
enum OperationStatus {}
enum Status {}
enum HttpStatus {}

Обратите внимание на то, что Http я написал не капсом. Аббревиатуры в названии любых переменных оформляются именно так, а не как HTTP. Также название enum-a пишется в PascalCase. Таким же образом оформляются и ключи enum-a:

// плохо
enum Status {
 SUCCESS,
 FAIL
}

// замечательно
enum Status {
 Success,
 Fail
}

Это самые частые ошибки, что мне приходилось комментировать. Все эти правила можно прочитать в официальном TypeScript Handbook и Google JavaScript Style Guide. Это не мои выдумки — это правила, закреплённые индустрией.

Спасибо за прочтение, это важно для меня ❤️

@prog_way_blog — чат — #web #theory #typescript