Frontend разработка

Рано или поздно, на проекте может возникнуть предложение генерировать типы API автоматически, например из свагера. При этом, обычно приводятся следующие плюсы: На практике же, обычно это превращается в следующее: В итоге вместо экономии времени и соответствия типов между фронтом и беком, получаем ровно противоположный эффект. Мало того, что вы потратите время на настройку и внедрение этой системы, так ещё придётся периодически её донастраивать и решать появляющиеся проблемы. При этом, ни кто не говорит что типы нужно писать руками, есть куда более простые решения не...

Сортировка — довольно распространённый вид операции с данными в JavaScript / TypeScript. Например, в одном из рабочих проектов .sort встречается 97 раз в 65 файлах. При этом важно, чтобы этот код был максимально читаемым и компактным. Обратите внимание, что некоторые примеры, для упрощения восприятия, будут без типизации. В конце будет ссылка на рабочий TypeScript код целиком. Рассмотрим следующий пример: const MAP_TYPE_TO_ORDER: Record<FeatureType, number> = { [FeatureType.Default]: 0, [FeatureType.Local]: 1, [FeatureType.Unknown]: 2, }; function sortFeaturesByTypeAndTitle(features: Feature[]): Feature[] { return [...

Даже опытные разработчики могут не увидеть ошибку в следующем коде: function sortItems<T>(items: T[]): T[] { return items.sort(/* some sort function */); } А она заключается в том, что метод sort не создаёт нового массива, а изменяет текущий. И это не очевидное поведение может привезти к появлению ошибок. Решается это довольно просто: function sortItems<T>(items: T[]): T[] { return [...items].sort(/* some sort function */); } Видимо это всех настолько “утомило”, что в спецификацию добавили метод toSorted...

Начать нужно с того, что весь (frontend) код который мы пишем, в конечном итоге загружается пользователями. Помимо самой загрузки, браузеру нужно этот код прочитать, проанализировать и выполнить. На всё это, как ни странно, нужно время, и чем больше этого кода, тем больше времени будут занимать все эти процессы. Стоит сделать важное замечание: даже если нужно выполнить какую-то небольшую часть кода, загрузить и проанализировать браузер его должен полностью. Предположим у нас есть веб-приложение с 10 страницами, из которых пользователи используют обычно 2-3, а к остальным обращаются редко, а то и вообще никогда...

Код-стайл (он же code style, coding standards, coding convention или programming style) — некоторый набор правил и соглашений для написания кода, над которым работает более одного разработчика. Зачем нужны эти правила? Первое, и самое важное — убрать разногласия между разработчиками, т.к. каждый привык писать по своему и считает что именно его вариант самый верный. Второе — предотвратить появление распространённых ошибок в коде. Например then() написали, а catch() забыли и в итоге у нас ошибка на проде. Третье — упростить чтение кодовой базы. В каком виде эти правила и соглашения должны быть реализованы?...