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

В рамках ведения проектов и код-ревью я частенько натыкаюсь на странности написания 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

Flash of unstyled content

Эта проблема — это тот случай, когда при загрузке страницы на долю секунды проскакивает нестилизованный контент. Как будто бы с сайта удалили все стили. И происходит это из-за того, что HTML уже построен, а стили — нет, или просто произошла ошибка при их загрузке.

Браузер уже имеет готовое DOM дерево, но всё ещё ожидает генерации CSS Object Model (CSSOM). FOUC появляется как раз до тех пор, пока не построится CSSOM. После его генерации создается дерево рендеринга и страница перерисовывается стилизованной. Выглядит это, зачастую, как вспышка белого на экране, особенно если сайт имеет какой-то специфичный фон. Отсюда и такое специфичное название.

Избежать подобной проблемы можно несколькими способами:

— Внести критический набор стилей в сам HTML, то есть описать основные стили в теге <style> в шапке index.html файла. Таким образом, мы гарантируем создание CSSOM ещё до отрисовки контента на странице, что решает проблему.

— Использовать проактивную загрузку стилей, то есть использовать preload для тега link, выглядеть это может примерно вот так:

<link rel="preload" href="style.css" as="style" />
<link rel="stylesheet" href="style.css" />

Тут мы помечаем файл style.css для предварительной загрузки, что также решает проблему.

Почему-же это важно? Всё дело в том, что наличие FOUC сильно портит пользовательский опыт, а в ночное время суток и вовсе бьёт по глазам, что вызывает отторжение у пользователей, особенно при использовании темной темы на сайте. Стилизация, в целом, играет важную роль в восприятии. Качественная работа со стилями может повысить продажи.

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

@prog_way_blog — чат — #web #theory

Пример тестового задания из Авито​

Интересностей пост, чтобы понимать, к чему стоит стремиться новичку фронтендеру. В этом посте кратко разберу тестовое задание на стажировку из Авито 2024 года.

Вот основные требования, которые я вычленил из описания задания:
— умение использовать React, его хуки в связке с TypeScript
— умение создавать свои собственные хуки
— умение реализовать переход на другую страницу в рамках приложения
— умение работать с API и Swagger, может пригодиться axios
— умение работать с переменными окружения
— сохранение и восстановление состояния из url query параметров
— базовое понимание и настройка Webpack
— базовое понимание Node JS
— базовое понимание docker
— базовое понимание самых простых UI unit тестов

По вёрстке, необходимо уметь отображать:
— Выпадающие списки
— Изображения
— Списки компонентов

Также необходимо понимать что такое адаптивная вёрстка и уметь верстать не только для своего ПК, но и для любого другого устройства, в том числе для мобильных телефонов, планшетов и прочего.

Что важно, но в тестовом об этом не сказано:
— базовое понимание того что такое архитектура, умение строить более-менее чистую файловую структуру проекта
— грамотное использование git в процессе разработки, хотя бы не одним коммитом проект нужно заливать
— понимание того, как работают стили, как сделать более-менее симпатичный и удобный интерфейс

Напугало ли вас это? Очень надеюсь, что нет. Если подумать, то это тестовое задание очень даже не сложное. Для начинающего разработчика, который пишет 3-4 проект в жизни, очень даже реально реализовать такое за пару дней в спокойном и размеренном темпе.

Кажется, что знать нужно очень много, но очень многое из тем, что я описал выше, на достаточном для выполнения тестового уровне, изучается максимум минут за 30, а если это не первый проект в вашей жизни, то с 80% требований вы уже точно встречались и уже имели бы нужный опыт в разработке.

Полный текст тестового задания

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

@prog_way_blog — чат — #web

Как сохранять состояние в URL

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

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

www.site.com/?name=progway

Соответственно, нам нужен инструмент, который позволит управлять этим состоянием. Как бы хотелось это видеть? Лично мне — ровно так же, как работает и обычный useState. Тогда от этого и будем отталкиваться:

const [name, setName] = useQueryState("name");
const [surname, setSurname] = useQueryState("surname", "Putnov");

Первым аргументом будем указывать ключ в URL, а вторым — изначальное состояние. Далее рассмотрим внутреннюю имплементацию хука и начнём с его интерфейса, тут всё достаточно просто:

type QueryValue = string | undefined;

function useQueryState<I extends QueryValue>(
  queryKey: string,
  defaultValue?: I,
) {
 // тело хука
}

Реализуем наш собственный хук на базе useSearchParams из react-router-dom для удобного доступа к состоянию URL-a. Если вы используете другой роутинг, можно использовать аналогичный механизм, который подойдёт именно в вашем проекте. Мы же будем его использовать для изменения URL-a и восстановления состояния из URL-a при маунте компонента. Если в URL-е уже есть состояние, мы будем использовать его. Если нет, будем использовать defaultValue:

const [searchParams, setSearchParams] = useSearchParams();

const [state, setState] = useState<QueryValue>(() => {
  const targetValue = searchParams.get(queryKey);

  if (targetValue !== null) {
    return targetValue;
  }

  return defaultValue;
});

Ну а всё что нужно далее — реагировать на изменение состояния и обновлять URL в соответствии с ним. Если в инпуте вдруг окажется пустая строка, то мы просто удалим наше состояние из Query параметров

useLayoutEffect(() => {
  setSearchParams((prev) => {
    if (state) {
      prev.set(queryKey, state);
    } else {
      prev.delete(queryKey);
    }
    return prev;
  });
}, [state, queryKey, setSearchParams]);

Да и всё. Всё работает.

Вот весь код, который, конечно же, не идеальный. Смысл поста — отразить основную суть.

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

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

Что делать новичку​

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

В этом посте выдам своё ИМХО для первых шагов в фронтенде. Как раз зафиксирую все необходимые ссылки, чтобы не писать одно и то же каждый раз. Далее я описываю конкретные шаги, которые нужно пройти последовательно:

1. Базовое понимание вёрстки, среды разработки
Вёрстка — это основа веб страницы. Нужно понимать какие есть теги и как они используются, уметь стилизовать элементы страницы и переиспользовать уже готовые части кода. В моём понимании, джун — тот, кто может худо-бедно сверстать ozon.ru
Лучший плейлист по вёрстке на русском языке

2. Система контроля версий
Важная часть, которую необходимо изучать сразу же после того, как вы сверстаете свои первые значимые странички. Пункт зачтён, когда на каждый проект вы умеете создавать репозиторий, владеете git add, commit, push, pull, checkout, fetch
Лучшая базовая статья по гиту

3. JavaScript
Ура, программирование. Нужно уметь решать алгоритмические задачи easy уровня с leetcode.com, понимать что такое DOM, события, event loop, замыкание. Тут важно сделать акцент на взаимодействии с HTML — добавление и удаление элементов на страницу, изменение их состояния, базовые умения работать с сетью по HTTP. Чем больше вы проведете времени на этом этапе, тем лучше. Рынку не нужны “React-программисты”. Знать базу очень важно. Аналогия очень простая: без хорошего понимания что такое sin и cos, вас никто не заставит решать квадратные тригонометрические уравнения. Не надо лезть во всякие реакты, прежде чем вы не знаете базы
Лучшее видео по JavaScript

4. TypeScript
На хорошую JS базу отлично ляжет TypeScript. Переходить к фреймворкам/библиотекам без TypeScript’a я вообще не вижу смысла.
Лучший базовый плейлист по TypeScript

5. Выбор фреймворка
Абсолютно всё равно что вы возьмёте для первоначального знакомства. Я глубоко убежден, что, например, из Vue в React и обратно, реально перекатиться за два полных рабочих дня. Да, вы не будете знать абсолютно всех мелочей, но сможете писать адекватный код. Лично я, если бы начинал, выбрал бы Vue или React. Без объяснения причин, мне просто прикольно поизучать их. Ангуляр никогда не вызывал интереса. Экзотику типа Svelte для первого знакомства мы не берём точно. В выбранный инструмент углубляться можно сколько угодно долго. Работу я бы начал искать после написания 3-5 серьёзных пет-проектов
Лучшие видео по React и Vue на канале Ulbi TV

6. NodeJS
Кто бы что ни говорил, я уверен, что NodeJS фронтендер знать обязан хотя бы на базовом уровне. Необходимо понимать что такое express, как обрабатываются заголовки, куки, полезная нагрузка запроса и тд.
Лучшие видео по NodeJS на канале Ulbi TV

Дальнейший путь вы можете обсудить со своим ментором, но я уверен, что 9/10 человек смогут и без ментора понять куда двигаться дальше на таком уровне. Если будут ещё вопросы, не стесняйтесь спросить в комментах.

Также абсолютно всем без исключения советую именно это видео. Ничего лучше вы не найдёте.

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

@prog_way_blog — чат — #web #blog #useful

for (var i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 1);
}

for (let i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 1);
}

@prog_way_blog — чат — #quiz

JavaScript там, где не ждали

Просто интересностей пост. Общались с одним из подписчиков на тему интересных кейсов применения JS и возникла идея описать их отдельным постом, подписчику привет. А вот и он.

Вообще, JavaScript многие воспринимают как язык веб-фронтенда. В последнее время для людей также прижилось его применение в разработке бекенда, например, на NodeJS, и мобильных приложений на чём-то типа React Native или ionic.

К сожалению или к счастью, это далеко не единственные варианты применения языка. Например, на JS легко можно программировать микроконтроллеры. Вот уж точно враг там, где не ждали. Есть множество различных интерпретаторов и библиотек JavaScript’a для микроконтроллеров, но самая популярная — это Espruino.

Вся эта экосистема открывает для языка такие области, как робототехника, встроенные системы, интернет вещей и т.д. То есть на JavaScript можно запрограммировать тостер, так что больше не жалуйтесь, когда вас просят его починить по причине “ты ж программист”

Также не забываем, что JavaScript отлично подходит для визуализации чего либо. Его можно использовать в научной среде для формализации данных, разработки игр, в том числе HTML5 игр, разрабатывать интерфейсы для банкоматов, касс самообслуживания, рекламных баннеров, интернет-меню, использовать для визуализации трёхмерных объектов с использованием чего-то типа three.js.

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

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

Ну и не будем списывать со счетов тонну библиотек. Кажется, что библиотеки есть уже буквально под всё.

Разные примеры применения JavaScript'a c фото — в комментариях)

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

@prog_way_blog — чат — #javascript

Сколько времени читается статья?

Очень интересная фишка в блогах и на других текстовых сайтах — указывать рядом со статьёй время её чтения. Видели что-то подобное: “Время чтения: менее 5 минут”?

Реализовать это максимально просто, для этого нужно два вводных параметра:
— количество символов в статье
— количество картинок в статье

В среднем, взрослый человек может прочитать за 1 минуту 1500 символов, а каждую картинку просмотреть за 12 секунд. Из этих параметров не сложно получить время прочтения в секундах:

const CHARACTERS_PER_MINUTE = 1500;
const SECONDS_PER_IMAGE = 12;
const SECONDS_IN_MINUTE = 60;

const calculateReadingTimeInSeconds = (articleLength: number, numberOfImages = 0) => {
    const charactersReadingTime = 
     articleLength / CHARACTERS_PER_MINUTE * SECONDS_IN_MINUTE;
    const imagesReadingTime = numberOfImages * SECONDS_PER_IMAGE;

    const readingTime = Math.ceil(charactersReadingTime + imagesReadingTime);

    return readingTime;
}

А далее секунды можно легко форматировать в читаемый промежуток времени через конструкцию switch (true), например, вот так:

const formatReadingTime = (seconds: number) => {
    switch (true) {
        case seconds < SECONDS_IN_MINUTE:
            return "Менее 1 минуты"
        case seconds < SECONDS_IN_MINUTE * 5:
            return "Менее 5 минут"
        case seconds >= SECONDS_IN_MINUTE * 5:
            return "Более 5 минут"
        default:
          return null
    }
}

Кода получается совсем не много, зато мы сильно улучшаем UX. Есть идеи какие ещё фишки можем разобрать? Пишите в комментарии)

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

@prog_way_blog — чат — #code

Дженерики​

Сколько я не бился в попытках объяснить что такое дженерик, кажется, что эта тема многим даётся тяжело. В этом канале я планирую написать несколько постов на эту тему, в которых разберу самые частые варианты использования дженериков на практике начиная от легкого к сложному. И начнем с самого простого:

Generic Type — обобщённый тип — это тип, который позволяет создавать по своему подобию другие типы или же динамически вычислять типы в зависимости от входных данных. Тут я максимально отойду от какой-то академичности и приведу простую аналогию:

Тип — это переменная
Дженерик тип — это функция, которая возвращает тип

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

const name = "Denis"

const getPerson = (name) => ({
 name,
 type: "person"
})

const person = getPerson(name)

В этом примере у нас есть переменная, на основе которой мы можем получить некоторый объект person используя функцию getPerson. А теперь рассмотрим нечто похожее в типах:

type Status = "success" | "error"

type Response<T> = {
 status: T,
 message: string,
 code: number,
}

type ApiResponse = Response<Status>

Уже в этом примере мы наблюдаем чем-то похожую ситуацию коду выше — мы создаём какую-то новую сущность на основе уже существующей. В первом случае — новый объект, а во втором — новый тип.

В таком контексте дженерики можно воспринимать как функции-конструкторы, которые, основываясь на некоторых входных параметрах, могут создавать новые типы. И из всего этого можно сделать вывод, что дженерики — это конструкторы типов.

На этом моменте у многих новичков часто возникает закономерный вопрос — а зачем их использовать? И ответ на него очень прост — почти за тем же, что и обычные функции.

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

// объявим сущности приложения
type User = {
 name: string,
 age: number,
}

type Task = {
 completed: boolean,
 title: string,
}

// ответ api в случае ошибки
type ResponseError = {
 code: number;
 message: string;
}

// ответ api в случае успеха
type ListResponseSuccess<T> = {
 data: T[],
 total: number;
}

// общий тип со всеми возможными
// состояниями ответа
type ListResponse<T> = ListResponseSuccess<T> | ResponseError

// типы для наших сущностей
type UserListResponse = ListResponse<User>
type TaskListReponse = ListResponse<Task>

// и их может быть сколько угодно...
type CarListResponse = ListResponse<Car>
type RoleListResponse = ListResponse<Role>
type UserGroupListResponse = ListResponse<UserGroup> 
// и тд

В этом случае мы создали тип конструктор ListResponse, который в дальнейшем сможем использовать для типизации всего нашего API без лишнего дублирования общих частей.

Это самый базовый пример использования дженериков, который может встретиться на практике. Не забывайте, что дженерики есть не только у типов, а и у интерфейсов, классов, функций… Даже у React-компонентов и хуков (что в целом тоже либо класс либо функция).

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

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

#web #theory #typescript

const shape = {
  radius: 10,
  diameter() {
    return this.radius * 2;
  },
  perimeter: () => 2 * Math.PI * this.radius,
};

console.log(shape.diameter());
console.log(shape.perimeter());

@prog_way_blog — чат — #quiz

Шпаргалка по Utility-типам в TypeScript

В этом посте разберу только самые часто используемые, посмотреть все utility-типы можно в официальной документации.

type Person = {
 name: string;
 surname: string;
 age: number
}

Partial<T>
Делает все ключи необязательными

type PartialPerson = Partial<Person>

// то же самое, что 
type PartialPerson = {
 name?: string;
 surname?: string;
 age?: number
}

Required<T>
Обратное действие Partial — делает все ключи обязательными

Required<Partial<Person>> === Person

Readonly<Type>
Запрещает изменять поля объекта

const person: Readonly<Person> = {
 name: "Denis",
 surname: "Putnov",
 age: 22
}

// ошибка, так как 
// person нельзя изменять,
// только считывать (readonly)
person.name = 'Денис'

Record<Keys, Values>
Создаёт тип из ключей и значений, указанных отдельно

// ключи могут быть только строкой
// значения - только числом
type WordCounter = Record<string, number>

type Status = 'success' | 'error'
type StatusCounter = Record<Status, number>

// то же самое, что и Record ранее
type StatusCounter = {
 success: number
 error: number
}

Pick<Type, Keys>
Выбирает только нужные ключи из типа и возвращает новый тип

// из типа Person выбираем только свойства
// name и surname
type PersonName = Pick<Person, 'name' | 'surname'>

// то же самое
type PersonName = {
 name: string
 surname: string
}

Omit<Type, Keys>
Удаляет ненужные свойства из типа и возвращает новый тип

// Из типа Person исключаем свойство 'age'
type PersonName = Omit<Person, 'age'>;

// то же самое
type PersonName = {
 name: string
 surname: string
}

Parameters<Function>
Возвращает тип параметров функции

type Foo = (a: number, b: number) => string
type Params = Parameters<Foo>

Params // [a: number, b: number]

ReturnType<Function>
Возвращает тип возвращаемого параметра из функции

type Foo = (a: number, b: number) => string
type Return = ReturnType<Foo>

Return // string

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

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