Расскажу, как я искал новую работу в IT в октябре (чуть меньше 1 месяца назад).

18 октября - я отрываю сайт rabota.by, вбиваю в поисковую строку "react". Мне находит примерно 150 вакансий. Из них было только 50 нормальных для 3+ годов опыта на позицию Front-End React.

Для каждой вакансии я находил рекрутера в LinkedIn. Просто писал в директ мое шаблонное сообщение:

"_Имя_, здравствуйте! Я нахожусь в данный момент в поиске новых карьерных возможностей. Наткнулся на вакансию в _Компанию_ на позицию React Developer, вакансия меня очень заинтересовала и готов предложить свою кандидатуру. Добавьте меня в ваш список контактов, чтобы я мог скинуть CV"

28 октября - у меня на руках 2 оффера. Один из них я принял 🔥.

Получается, нашел работу за 10 дней. Всего у меня было 4 созвана с рекрутерами и 3 технических собеседования. Многих, конечно, я отсеивал в переписке в LinkedIn, потому что не подходили под мои критерии.

Безусловно то, что я писал в личку в LinkedIn рекрутам, сыграло огромную роль в этом быстром поиске. Если бы я просто откликался через сайт (условный rabota.by или hh.ru), то ждал бы довольно долго ответ на мой отклик. Поэтому выводы делайте сами 😏

Я часто заказываю себе доставку продуктов на дом. И всегда это минимум 5 бутолок воды (1,5 л каждая) + куча еды. И мне обычно привозили все это на машине, потому что обычному человеку нести эти пакеты на спине ну уж очень тяжело.

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

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

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

Как я инициализирую проект на React и создаю его структуру?

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

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

Обычно, я делал папки core, components, common и т.д. в корне (в src) проекта. И когда стояла задача добавить, например, вспомогательную функцию (helper) в проект, то я думал: "ну добавлю эту функцию, наверное, в common". А если нужно добавить новую фичу? Тогда добавляем ее в components, делаем кучу вложенных компонент, зависимых между собой, прикручиваем ко всему этому глобальное состояние. И таким образом увеличиваем проект и строим все больше и больше зависимостей между компонентами, модулями.

Так вот, по описанию можно понять, что это все не очень хорошо. Мне порекомендовали методологию Feature Sliced Design (FSD) для решения таких проблем. FSD описывает свод правил и соглашений по организации кода. Главная цель данной методологии — сделать проект понятным и структурированным.

Сейчас я в процессе инициализации проекта при помощи FSD. Пока что методология меня радует, так как помогает структурировать наш код и ограничить нас в некоторых моментах, чтобы выполнялся шаблон Low Coupling & High Cohesion (слабая зацепленность и сильная связность).

Пока проект не стартовал, и я не смог протестировать методологию в работе с командой и при добавлении новых фич в приложение. Буду смотреть, как все будет развиваться с применением FSD. В процессе буду отписывать сюда по результатам 😉

Лучшая либа для форм в React: Formik VS React Hook Form

На моем текущем проекте у нас встала задача выбрать библиотеку для работы с формами в React. Раньше в компании юзали Formik, а я слышал, что Formik - говно, но не знал толком почему. Поэтому решил поискать в инете альтернативы и, спойлер, я их нашел.

Так вот, в этом посте я расскажу, почему Formik жестко проигрывает React Hook Form. После прочтения ваши навыки формошлепства улучшатся минимум на 70% 😁.

Чем Formik плох?

1. Обновления формы после каждого изменения в любом input. Представьте форму, где есть, допустим, 10 input-ов разных типов (обычный input, select, textarea, file upload и др). Вы вводите символы в 1-й input, а это вызывает обновление всей формы. И обновление происходит на ввод каждого символа. Представьте, как проседает производительность!!!

React Hook Form, наоборот, изолирует обновление конкретного input-а. То есть, если в форме из 10 input-ов изменяется значение 3-го, то обновится только этот 3-й input (а не ВСЯ ФОРМА!). В основном, такая оптимизация Hook Form реализована благодаря неконтролируемым компонентам. В таких компонентах используется ref для получения значений input-а, а не value + onChange, как в контролируемых.

2. Ну и также немного технических характеристик.

Размер либы: Formik - 12.6kb; React Hook Form - 5.2kb.
Зависимости: Formik - 9; React Hook Form - 0 (нуль зависимостей!).

В общем и целом, на Formik стоит смотреть в последнюю очередь при выборе библиотеки для работы с формами. Как по мне, React Hook Form - это идеальный выбор для большинства решений. Есть еще хорошая либа React Final Form, но она не поддерживает валидацию через yup, поэтому мы от нее отказались на проекте.

А вы какие библиотеки используете при работе с формами? Напишите в комменты 😏.

————————————

Материалы:

Formik,
React Hook Form,
Статья "React Hook Form vs. Formik: A technical and performance comparison".

Впервые сам поставил и собрал елку! 🎄🥳

Всех поздравляю с наступающим Новым 2023 годом! 🎄🍊

Желаю в новом году работать по 2 часа в день вместо 8, либо вообще не работать в IT. Ну и тем кто еще не в IT, желаю найти работу на этом трудном рынке в данный момент 😉

Прикупил себе микрофон. А это значит, будут новые видео на моем YouTube! 🔥

P.S. Если кому интересно, то модель называется Lorgar LRG-CMT521.

На моем YouTube вышло новое видео! 🔥 Посмотреть его можно здесь.

Создаем NPM библиотеку UI компонентов. React, Typescript, Storybook. Публикуем на GitHub Packages

————————————

Вот полезные материалы и упоминания из ролика:

1. В видео в dependencies мы установили только react и данная библиотека не попадает в итоговый билд (в папку dist), благодаря параметру external.
Скорее всего, у вас в библиотеке будут использоваться и другие npm-модули (например, lodash). И чтобы эти модули попадали в билд, вам необходимо установить пакет @rollup/plugin-node-resolve. Также в нем можно указать либо исключить конкретные модули для папки dist при помощи параметра resolveOnly.
2. Начальный код. Склониуйте его себе, если будете разрабатывать библиотеку вместе со мной по видео. tsconfig, eslintrc и другие конфиги также смотрите по этой ссылке);
3. Настройка webpack для storybook;
4. Команда для установки wepback5 модулей:

npm install @storybook/builder-webpack5 @storybook/manager-webpack5 -D

5. Шаблон для файла .npmrc:

registry=https://registry.npmjs.org/
@YOUR_GITHUB_USERNAME:registry=https://npm.pkg.github.com/
//npm.pkg.github.com/:_authToken=YOUR_AUTH_TOKEN

6. Шаблон названия библиотеки для файла package.json:

"name": "@YOUR_GITHUB_USERNAME/YOUR_REPOSITORY_NAME",
"publishConfig": {
"registry": "https://npm.pkg.github.com/YOUR_GITHUB_USERNAME"
},

7. Необходимые зависимости storybook для работы контролов:

"@storybook/addon-essentials": "^6.5.13",
"@storybook/addon-interactions": "^6.5.13",
"@storybook/addon-links": "^6.5.13",

8. Начальные зависимости в package.json.
9. Репозиторий с итоговым кодом.

Когда применять React.memo? Оптимизации в React

В общем и целом, React быстрый, если придерживаться его best practices и в нужных местах применять оптимизации при помощи React.memo.

Хочу поговорить про этот React.memo, потому что штука очень важная и я ее в последнее время часто применяю. Если кто не знает, то React.memo автоматически проверяет, изменились ли пропсы. И если они не изменились, то React не вызовет ререндер и вернет результат прошлого рендера.

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

1. Первым делом нужно посмотреть, можете ли вы вынести состояние в другую компоненту или разбить основную компоненту на подкомпоненты.
2. Если после того, как вы разбили компоненты, у вас проблема с лишними ререндерами не решилась (либо решилась частично), то стоит применить React.memo.

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

Если какие-то пропсы являются объектами и (или) функциями, то значения этих пропсов необходимо обернуть в useMemo и useCallback соответственно. Если вы этого не сделаете, то React.memo уже не будет выполнять свою главную функцию. Конечно, если ваше значение имеет тип данных объект и хранится в useState, то ничего в useMemo оборачивать не нужно.

А вы используете React.memo в своем коде? 😏

В последние полгода я работаю только из дома. Все время сидеть в квартире за ноутом довольно трудно, поэтому вечером либо в обед я прогуливаюсь до кофейни и работаю оттуда.

Кстати, это довольно удобно и очень даже атмосферно ☕️

А вы в каком месте в основном работаете? 😏

Монтируется новый видос на YouTube. Выйдет в воскресенье (сегодня) либо в начале следующей недели. 😉

Наконец-то добрались руки до 3-й части видео про верстку (адаптив) 🔥

Плейлист по версте макета на HTML и SCSS можно найти здесь.

Всем привет! На моем YouTube вышло новое видео 🔥

Адаптивная верстка сайта c нуля для начинающих | HTML и SCSS (SASS)

Посмотреть можно здесь 👈

————————————

Вот полезные материалы и упоминания из ролика:

1. Конечный код на GitHub.
2. Начальный код на GitHub.
3. Макет из Figma.
4. Файл mixins.scss с миксинами для создания media запросов.
5. Единица измерения rem.
6. Использование миксинов в SASS (SCSS)

На моем YouTube 1000 подписчиков 🥳 Всем спасибо!

P.S. Но монетизации все равно не будет 🥲

Более крутая альтернатива Storybook?

Недавно нашел инструмент, который может заменить Storybook во многих React-проектах. Этот инструмент называется @ladle/react.

Меня всегда напрягал Storybook следующими вещами:

1. Долгий релоуд стори после внесения изменений в код;
2. Долгая сборка билда всех сторей;
3. Куча лишнего кода, который требуется для написания стори.

Как говорится в документации ladle: "Ladle is almost 20x smaller" (имется в виду билд почти в 20 раз меньше, чем у Storybook).

Я попробовал переписать наш текущий Storybook на проекте на @ladle/react. Всего примерно было 30 сторей. Вот результат, который я заметил:

1. Релоуд стори работает намного быстрее после внесения изменений в код.
2. Размер итогового билда всех сторей от Ladle составляет 1.8 мб, у Storybook - 13.0 мб. В 7 раз меньше! Конечно не в 20, но тоже много.
3. Количество строк кода в файлах сторей уменьшилось на 10-40%. Это дает понять, что в Storybook есть много шаблонного кода, который обязателен для его работы.
4. Да и как по мне, настроить Ladle намного проще и ему не нужно куча дополнительный пакетов, как storybook.

Как-то так, буду теперь предлагать на проекте убрать Storybook и внедрить Ladle 😄

Как безопасно отрендерить HTML-строку в React? dangerouslySetInnerHTML

Всем привет! Хочу поделиться своим опытом использования dangerouslySetInnerHTML. На моем текущем проекте бэкендеры решили, что грамотно возвращать HTML-строку в запросах. Вот пример того, какая строка может прийти "Click <a href="/link" >here</a>".

Так вот, эту HTML-строку нужно правильно отрендерить в React. И при том чтобы не было дыр в безопасности, так как мы знаем, что в HTML-строку можно вставить вредоносный код.

Если у вас есть HTML-строка, и вам ее нужно отрендерить в React, то правильным выбором будет использовать атрибут dangerouslySetInnerHTML. Как говорится в самой доке React:

"dangerouslySetInnerHTML is React’s replacement for using innerHTML in the browser DOM. In general, setting HTML from code is risky because it’s easy to inadvertently expose your users to a cross-site scripting (XSS) attack".

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

<span dangerouslySetInnerHTML={{__html: DOMPurify.sanitize(htmlString)}} />

————————————

P.S. Я сделал для вас пример переиспользуемой компоненты, которую можно юзать для рендера HTML-строки в React. Можете потыкать компоненту по ссылке.

Вообще, подключение библиотеки для решения только одной небольшой проблемы - это не самый лучший вариант. Но пока что другого выхода я не нашел. В Browser API уже появился метод setHTML, который решает эту задачу с безопасностью innerHTML и dangerouslySetInnerHTML. Но этот метод еще в статусе Experimental.

Поэтому рассмотренный выше вариант кода является неплохим решением.

Проблема с useMutation в react-query

На проекте мы используем react-query и совсем недавно я заметил необычную особенность в хуке useMutation. Проблема в том, что при повторном вызове mutateAsync, параметр data у мутации сначала изменяется на undefined, а затем уже на значение, которое пришло из запроса.

И если смотреть на это при изменении в UI, то получается "скачущий" текст, что конечно же является не самым правильным поведением для пользователя. Получается примерно так:
"data при 1-м запросе" --> undefined --> "data при 2-м запросе" --> undefined --> ""data при 3-м запросе" и т.д.

Я перекопал в интернете много вариантов, почему useMutation так работает, и как пофиксить это поведение, но ничего не нашел.

Поэтому я придумал написать кастомный хук useMutationState, который решил эту задачу. Потыкать его можно в Codesandbox по ссылке.

————————————

P.S. Если у вас есть решение получше, чем мой кастомный хук useMutationState, то оставляйте предложения в комментариях 😉

Господа программисты, мне от вас нужно инженерное решение. Я уже обсуждал варианты решения с друзьями из IT, пока нет ничего на 100% рабочего.

Проблема: бомжи терроризируют район Маяк Минска (это НЕ шутка!). Сейчас все мусорные баки закрыты в беседках из железных листов. На каждой беседке есть дверь с кодом. Код 2-значный и нужно вводить цифры на замке одновременно.

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

Задача: необходимо придумать решение, благодаря которому бомжи бы не ходили по району с целью опустошения мусорок.

Уже предложенные варианты:
1. Беседки с мусорными баками будут открываться при помощи чипа. Но проблема в том, что если бомжу в руки попадется чип, то вся система «защиты» рухнет.
2. Вызвать несколько раз милицию, чтобы они разогнали бомжей. Это чересчур легко, нам нужно инженерное решение!

А КАКИЕ У ВАС ПРЕДЛОЖЕНИЯ, ГОСПОДА?

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

Кратко покажу мои последние диалоги в LinkedIn.

М: Здравствуйте, мне интересна ваша вакансия. Она все еще актуальна?
Р: Добрый день, Максим! Да, актуальна.
М: Подскажите вилку ЗП по вакансии?
Р: Знаете, мы отталкиваемся от ожиданий кандидата. Какие у вас ожидания?
М: N$ чистыми в месяц. Вам подходят такие условия?
Р: Ой нет, это много для нас, мы можем дать максимум X$.

Неужто они надеются найти тех, кто попросит гораздо меньше от их максимальной вилки? 🤔

✌️React Fiber для собеседований

Когда я готовлюсь к собесами, то всегда ожидаю от интервьюера глубокие вопросы по React. Одна из таких тем - это React Fiber. Я довольно часто повторяю данную тему, поэтому я сделал для себя небольшой конспект ключевых тезисов, которые помогают рассказать про Fiber на собесе. Поделюсь с вами.

Fiber это...

Fiber – переделанная реализация алгоритма Reconciliation.

Ключевые задачи Fiber:

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

Fiber Call Stack

Fiber переделывает поведение обычного Call Stack. Единицу Fiber можно рассматривать как элемент стека (либо единицу работы).

Главное преимущество Fiber Call Stack в том, что он может хранить элементы стека в памяти и исполнять эти элементы (выполнять работу) когда это необходимо, то есть Fiber Call Stack может планировать выполнение задач (scheduling). А обычный JS Call Stack так не может, он будет продолжать выполнять работу до тех пор, пока стек не опустеет.

Полезные ссылки:

1. React Fiber Architecture
2. Подробно о React Reconciliation, или Как React добился 60 fps

P.S. В следующем посте расскажу про структуру Fiber-объекта (type, key, pendingProps, memoizedProps, pendingWorkPriority и др)

✌️Структура Fiber

Ссылка на 1-ю часть про React Fiber.

Единицу Fiber можно рассматривать как элемент стека, но можно и как экземпляр компоненты. И у данной компоненты (объекта) есть несколько ключевых полей.

1. type - тип компоненты. Для обычных компонент как HTML-элементов это строка ('div', 'span' и др). Для кастомных компонент (<MyComponent /> например) type - это функция или класс.

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

3. child - это то, что возвращает компонента для рендера. В примере ниже в параметре child будет храниться MyChild.

function Parent() {
return <MyChild />
}

4. return - это Fiber элемент, к которому должна вернуться программа после обработки текущего Fiber элемента.

Из примера кода выше значением return для MyChild будет Parent.

5. pendingProps и memoizedProps - pendingProps это пропсы в начале выполнения, memoizedProps - пропсы в конце выполнения. Если данные пропсы равны, то это знак для алгоритма React, что предыдущее возвращаемое значение можно переиспользовать. А это значит, что нет необходимости в ререндере.

6. pendingWorkPriority - это число, которое обозначает приоритет единицы работы (задачи для выполнения). Чем больше число, тем ниже приоритет (всего 6 приоритетов).

Алгоритм React использует pendingWorkPriority для поиска следующей единицы работы, которую необходимо выполнить.

P.S. Это конечно же не весь список, но для базового понимания хватит.