Что-то на программистском

Не популярное мнение того, кто побывал с обеих сторон в больших количествах. Технические собеседования на позицию фронтенд разработчика, что с ними не так и как это исправить. Обычно, тех. интервью состоит из двух этапов: теория и “лайф-кодинг”. Давайте по порядку: Важно понимать кого и на какую позицию вы собеседуете. Одно дело начинающего, и совсем другое старшего разработчика или вообще тех. лида. Но и в том и другом случае, это должно быть именно СО-беседование, т.е. двух-стороннее общение, а не допрос или экзамен как это обычно бывает. И да, схемы типа “мы тебя сейчас поспрашиваем, а потом в конце ты задашь свои вопросы” не тянут на общение...

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

Не так давно я писал зачем нужно разделять код на чанки, а теперь давайте рассмотрим некоторые нюансы настройки Webpack, связанные с этим вопросом. Для начала, создадим папку src и добавим туда три файла, index.js и два других (предположим foo.js и baz.js), динамически импортируемых в первый. Затем добавим минимальный файл конфигурации: // webpack.config.js module.exports = { entry: './src/index.js', output: { // про contenthash как нибудь в другой раз filename: '[name].[contenthash].js', }, }; Кстати, когда речь идёт о долгосрочном проекте, рекомендую всегда самим настраивать сборку, а не использовать готовые решения...

Сортировка — довольно распространённый вид операции с данными в 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...

Один из примеров того, как не нужно делать в React. Есть некий компонент в котором через меню открывается одно из модальных окон: function Comp() { return ( <> <Menu /* выбор какое окно открыть */ /> <ModalA isOpen={modal === 'a'} /> <ModalB isOpen={modal === 'b'} /> <ModalC isOpen={modal === 'c'} /> </> ); } Каждое из этих модальных окон это форма которой необходимы некоторые данные с сервера. React выполняет все эти компоненты, и как следствие, загружает все необходимые им данные разом. Получаем лишнюю нагрузку на браузер клиента и на сервер. Дополнительной проблемой является то, что при закрытии такой формы, её состояние не сбрасывается, т...

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

Представим, что мы пишем свою реализацию “хранилища” данных, которое должно возвращать примерно такое состояние: interface State<T = unknown> { status: 'loading' | 'error' | 'success', error: Error | undefined, data: T | undefined, } На первый взгляд может показаться что всё ок, однако это не совсем так. К примеру, проверка status ничего не скажет нам о состоянии других полей: if (state.status === 'success') { console.log(state.data.toFixed()); // Получаем ошибку // 'state.data' is possibly 'undefined'. } Решаем проблему через union тип, добавляя три (по количеству состояний)...

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

Как сократить время локального запуска проекта, например, с 16 до 1 секунды? Если вы используете Webpack 5.17+, можно отложить сборку конкретного кода (чанка) до момента пока он не понадобится: experiments: { // true должно быть только при локальном запуске lazyCompilation: true, }, В итоге, чем лучше код разделён на чанки, тем меньше времени придётся ждать...

На первый взгляд может показаться что одно можно легко заменить на другое, ну или как минимум не трогать код проекта, но это не так. Я столкнулся с двумя моментами, но скорее всего их больше. 1. Обработка ошибок загрузки (не существующих) чанков Если ваша сборка подразумевает что имена чанков между сборками могут отличаться, в хэш части, то хорошей практикой будет добавить обработку ошибки загрузки не существующих файлов. Webpack, в данном случае, возвращает специализированные ошибки: Для JS: error.name = ChunkLoadError Для CSS: error.code = CSS_CHUNK_LOAD_FAILED Vite же, для js вернёт обычную...

При переходе на очередной проект, столкнулся с тем, что его локальный запуск происходит не быстро. Репозиторий не сказать бы что большой, поэтому 42 секунды (mac air m1 2020) для него многовато. Итак, вот один из примеров, что можно попробовать сделать в подобном случае: Для начала, нужно понять на что именно уходит это время. Для любого инструмента сборки есть или встроенные средства, или стороннее расширение. В нашем случае, это speed-measure-webpack-plugin. Устанавливаем, оборачиваем им наш конфиг сборки, запускаем и видим следующее: General output time took 42.15 secs eslint-webpack-plugin took 21...