Всем привет!

Сегодня без мухлежей буду писать нормальную мини-статью.

Хочу поговорить про такую важную тему, как перевод проекта на TS.

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

Данная статья как раз для вас!

Также если у вас есть проект, который был плохо переведен, то я уже писал пост про то, как это можно исправить (ищете по ключевой фразе “suppress-ts-errors”).

Собственно, к самой теме.

В первую очередь, хотел бы задать правильный настрой, при переводе проекта.

Не нужно ожидать, что через месяц уже все ваши файлы будут переведены на TS. Это можно сделать, но стоит ли?

Ответ, надеюсь, у вас тоже нет.

Айюб, а как же тогда переписывать проект?

В моем опыте хорошо работает такой подход:

1) Добавляем в проект возможность писать TS файлы. Очень важно, tsconfig должен быть как можно более строгим с самого начала. А то потом намучаетесь его исправлять.

Единственное что, даем импортировать JS файлы, так как большая часть проекта пока на нем.

2) Пишем весь новый функционал на TS файлах.

3) Понимаем, какой функционал часто импортируется в другие файлы и меняется.

Такие куски можно начать переписывать вместе с какими-то задачами.

В целом, флоу такой. Если человек хочет заимпортировать модуль, написанный на JS он:

а) Импортирует его как есть, по возможности добавляет JSDoc, чтобы типизация в TS файле была правильная.
б) Если модуль старый и скорее всего не будет меняться, лучше вместо JSDoc написать .d.ts файл.
в) По желанию переписывает на TS. Это сделать намного проще, когда уже есть какие-то JSDoc аннотации + есть какое-то понимание того, как работать с тайпскриптом.

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

По началу будет все идти медленно, так как разрабы будут только начинать знакомиться с ТС. Так же все модули будут написаны на JS, что будет давать дополнительную сложность.

Однако через некоторое время, когда у вас уже будут часто используемые модули покрыты JSDoc, станет не так сложно переписать их на TS.

Также легаси куски будут описаны в .d.ts, что позволит не трогать их и избежать ненужных проблем.

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

Тогда уже можно и начинать процесс переписывания. Ключевая вещь тут не заставлять это делать. Можно предлагать на ревью, например.

Либо сделать какое-то необязательное правило. Если тронул старые файлы, перепиши хотя бы один.

Идей тут много. Но в любом случае рано или поздно кто-то перепишет эти файлы, потому что так удобнее. Просто произойдет это не сразу.

В общем, думаю идея тут ясна. Не надо закапывать продуктовую разработку на несколько спринтов. Делайте так, чтобы вся работа шла параллельно.

#devtips #typescript

Всем привет!

Хотел бы поделиться одним советом для тех, кто проходит курсы, учит английский или может занимается блогом или ютубом - в общем, делает что-то, что требует мозговой активности.

И совет простой, но почему-то самому часто бывает сложно его применять.

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

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

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

Не зря ведь говорят: “плати себе первому”. К времени, думаю, этот совет тоже относится.

P.S. Что думаете по поводу таких советов, на прямую не относящихся к программированию. Интересно или нет?

#devtips #learning

Друзья, тут пока готовил урок по i18n - решил собрать решение, которое я обычно использую на своих проектах (Про то, почему не юзаю что-то готовое - расскажу в видео).

Основные принципы моего решения:

- Полная типизация (насколько это возможно).
- Не большой размер (всего примерно 200-300 строк).
- Простота. Не вижу смысла поддерживать большое кол-во форматов, это только добавляет ненужную сложность.

Так вот, хотел спросить, есть ли смысл выносить его в пакет, чтобы вы могли пользоваться им?

Из фичей, что там есть:

- Полная поддержка TS, правильно подхватываются типы на основе переданных ключей. Не надо ничего писать руками. Также из уникальных фичей - будет требовать передать count если у вас плюральный ключ.
- Стандартный функционал - выбор ключей на основе языка, интерполяция через {{}} синтаксис, плюрализация.
- Хуки для React.
- Компонент для сложных переводов (кейсы когда внутри переденного текста должна быть ссылка или любой другой компонент).
- Асинхронная подгрузка ключей.
- Возможность работы с удобным для вас форматом плюрализации (можно конфигурировать).

Из того, с чем могут быть проблемы в начале:

- Различные кейсы с SSR. По идее ничего особенного там не должно быть, но еще не тестил.
- Поддержка плюрализации для разных языков (В целом я могу взять из какой-нибудь другой либы на пока, а потом подкорректировать).
- Небольшие неудобства с АПИ (тут как раз нужен будет фидбэк).
- Интеграции с хранилищами ключей и инструменты для работы с различными сборщиками (webpack, vite и тд.). Должно доехать со временем.
- Пока интеграция только с React, потом можно будет донести для других фреймворков.

Из того, что пока не планируется:

- Поддержка вложенных структур данных (максимум 1 уровень для плюрализации). Это сильно усложняет типизацию. В целом обсуждаемо, но пока не вижу зачем это нужно.
- Встроенный перевод для дат/времени. В любом случае никто не работает с датами сам, а переводы в библиотеках уже есть.

Какие тут плюсы для меня?

- Не нужно копировать свое решение из проекта в проект.
- Фидбэк от комьюнити о том, что сделано плохо.
- Есть интерес поработать над библиотекой + галочка в резюме, если проект вдруг наберет звезды.
- По мере развития будут темы для постов в телеграмм и видео.

В общем, отпишите, что думаете.

Всем привет!

Работаю сейчас над фичой, когда нужно у пользователя дополнительно просить имя на латинице, если вдруг он написал его на удобном ему (не латинском) языке.

Казалось бы, все просто. Проверил регуляркой, что все символы подходят, если нет - то показываешь другой скрин и просишь написать еще имя на латинице.

Что-то типа такого:

const nonEnglishLetters = /[^a-zA-Z]/;

if (nonEnglishLetters.test(name)) {
    showEnglishNameScreen();
}

// do something else

Однако, тут есть проблема. Мы ведь проверяем на английский алфавит, а не на латинский (таких оказывается не мало).

Решением на бекенде было просто использовать пакет unicodedata. Похожие библиотеки есть на js, но весят они как 2 наших бандла, так как хранят инфу о всех символах.

Собственно, после небольшого ресерча нашел, что есть такая вещь, как unicode regular expressions.

В целом о возможности использовать unicode'ы в регулярках я знал, но не слышал о скриптах, блоках и категориях (что-то типа \w+ в обычной регулярке).

Так вот, оказалось можно проверить на символ из любого алфавите с помощью /\p{L}/u.

А если нужен символ из латинского алфавита, то вот так - /\p{Script=Latin}/u.

Таких конструкций довольно много, подробнее можете почитать тут:

https://www.regular-expressions.info/unicode.html

#devtips #regex

Также, касательно пропущенного вчера поста и видосов на прошлой неделе.

Про все помню. Розыгрыш будет. Пока накопилось 2 видоса и 1 пост.

На этой неделе снял 2 видоса, жду когда они выйдут с монтажа. Скорее всего успею выложить только 1.

В планах сделать сразу большой розыгрыш. Может повысить призы (2 сессии менторинга либо $100).

Всем привет!

Наконец вышло мое видео про i18n, и как я с ним работаю.

Поделюсь очень многими дельными советами из своего опыта, объясню почему я не использую готовые пакеты и в конце покажу свое решение для i18n.

Оставляйте комментарии и лайки - это помогает каналу быстрее расти.

https://youtu.be/skFxXao2ry4

Друзья, все таки решил выложить свое решение для i18n на npm, кажется, что есть люди, кому это может быть полезно.

Собственно, вот ссылка на GitHub:
https://github.com/Ayub-Begimkulov/i18n

И вот ссылка на npm:
https://www.npmjs.com/package/@ayub-begimkulov/i18n

Выпустил пока в персональном скоупе (@ayub-begimkulov/i18n), так как не придумал еще название.

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

Накидайте звезд, если хотите, чтобы проект развивался.

Из интересного, в комментариях под видео мне подсказали, что у Intl есть встроенный способ подбирать плюральную (множественную) форму - Intl.PluralRules.

Вот небольшой пример:

const rulesRu = new Intl.PluralRules('ru');

rulesRu.select(0); // 'many'
rulesRu.select(1); // 'one'
rulesRu.select(2); // 'few'
rulesRu.select(3); // 'few'
rulesRu.select(10); // 'many'

Попробовал и с другими языками - работает отлично.

В плане [поддержки браузеров](https://caniuse.com/intl-pluralrules) - тут кажется тоже нету проблем (все, кроме IE).

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

export function createPluralize(locale: string) {
  const rules = new Intl.PluralRules(locale);

  const pluralize = (count: number) => {
    return rules.select(count);
  };

  return pluralize;
}

А если нужна поддержка старых браузеров - можно просто написать реализацию самому.

Новую версию планирую выпустить сегодня вечером.

Старые функции pluralizeRu/pluralizeEn удалять сразу не буду, побудут некоторое время в статусе deprecated.

Как-то так, буду держать в курсе.

#devtips #i18n

Всем привет! Давайте пока не забыл проведем розыгрыш.

Для тех кто не в курсе, я пообещал выпускать 2 видоса в неделю и 1 пост в день. Если пропускаю - то разыгрываю $50 или 1:1 консультацию (на выбор победителя).

Так вот, на позапрошлой неделе я болел, ток что было 0 видосов. На прошлой же я пропустил 1 пост и 1 видео.

Давайте чтобы не мелочится повысим призы - 2 победителя. Выбрать можно на выбор либо $100, либо две 1:1 консультации.

Как всегда, оставляем ровно 1 коммент под следующий постом! Под данными постом ничего не будет засчитываться.

Победителя буду выбирать завтра, примерно в этом же время.

Пост для сбора комментариев на розыгрыш.

Всем привет!

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

И так, вот результаты.

Сейчас буду отсчитывать победителя.

И так, под номером 20 у нас @AAkab11.

Так, кто-то удалил свой коммент вначале…

В общем, еще раз перепроверил. Второй победитель у нас Артем.

Он было 406, до того, как кто-то начал удалять комменты.

На будущее напишу бота, чтобы не было таких проблем.

Напишу каждому из победителей в личные сообщения.

Итак, друзья.

Делюсь новостями фронта за эту неделю, которые мне показались интересными.

Deno выпустила версию 1.31 с поддержкой package.json. Теперь работать с npm пакетами будет намного проще. Кажется, что они работают над тем, что максимально просто было мигрировать с node проектов на deno.
https://deno.com/blog/v1.31

Также наткнулся на статью про релиз Astro 2.1, там ничего особенного нету. Однако из нее я узнал про такой формат, как marcdoc от stripe. Поддержку его добавили из-за перформанса, но в целом интересно посмотреть, насколько он станет популярен.
https://astro.build/blog/astro-210/#built-in-image-support

Статья от Astro про перфоманс различных фреймворков.
https://astro.build/blog/2023-web-framework-performance-report/

Vercel поделился причиной, почему Turborepo съезжает с go на rust. Думаю вам тоже будет интересно почитать.
https://vercel.com/blog/turborepo-migration-go-rust

#devtips #news

Всем привет!

Наконец вышло новое видео. В этот раз поговорим про TypeScript.

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

В следующие 2-3 недели буду продолжать выпускать видео по TS, разберем много полезных тем, также поделюсь практическими примерами использования.

Оставляйте лайки и фидбэк в комментариях, и если вам понравилось видео - поделитесь с друзьями, это помогает каналу быстрее расти.

https://youtu.be/lnO4YX0Luso

Всем привет!

Недавно наткнулся на интересное видео от Theo и задумался, что ведь и в правду не нужно везде пихать тайпчекинг.

Он же должен быть только в одной таске в CI. По крайней мере жесткий.

Например, очень часто я раньше ставил проверку типизации на unit и e2e тесты, хотя она там и не нужна, только замедляет запуск тестов. То же самое касается и билда.

Как часто у вас было, что в проекте появилась 1 маленькая проблема с TS и из-за этого все такси в пайплайне красные? И даже потестить код нельзя, из-за того, что забыл переменную неиспользуемую удалить.

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

Я уже давно начал использовать отдельный конфиг для дева и для тайпчека, так как в деве, например, noUnusedLocals/noUnusedParameters - не несут никакого толка, только мешаются.

Однако после этого видео понял, что лучше для сборки и юнит/е2е тестов тоже все убрать. Оставить только ошибки в терминале/консоли для дева и отдельную typecheck таску в CI с жестким конфигом.

А что вы думаете по этому поводу? Как у вас все настроенно в проекте?

#devtips #typescript

Всем привет!

Продолжаем наш плейлист по TypeScript. В сегодняшнем видео поговорим про такую важную тему, как type guards и type assertions.

Детально разберем, что это такое, когда их использовать, какие есть встроенные type guard’ы и как превратить вашу функцию в type guard или type assertion.

Обязательно оставляйте лайки и фидбэк в комментариях. Также, если видео было полезно, поделитесь им с друзьями, это помогает каналу расти.

https://youtu.be/xsyykEdOQ7E

Всем привет!

После моего последнего видео многие из вас спрашивают о комментарии ^? внутри TS кода, который показывает тип значения, находящегося строкой выше над комментарием.

Данная фича по дефолту работает в TypeScript playground на их официальном сайте. Однако если вы хотите иметь такое же поведение в VSCode - нужно скачать плагин vscode-twoslash-queries.

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

#devtips #typescript