Статья про мемоизацию оказалась объёмной и включает в себя разбор hoc memo, хуки useMemo и useCallback, затрагивает тему useRef. Было принято решение разбить статью на 2 части, в первой части разберем когда нужно и когда ненужно использовать memo, какое у него api, какие проблемы решает. Во второй части разберем хуки useMemo, useCallback, а также некоторые проблемы этих хуков, которые можно решить с помощью useRef.

В прошлых статьях мы разбирали как работать с useState и с useEffect. Знаем: код компонента будет выполняться каждый раз при его обновлении. Отсюда возникает проблема - данные и сложные вычисления будут теряться, также будет происходить лишнее обновление дочерних компонентов. Эти проблемы решает хук useMemo и обертка над ним useCallback, но оба работают в связке с memo hoc.

Привет, друзья!

В данном туториале я покажу вам, как тестировать компоненты на React с помощью Jest и Testing Library.

Список основных задач, которые мы решим на протяжении туториала:

1. Создание шаблона React-приложения с помощью Vite.
2. Создание компонента для получения приветствия от сервера.
3. Установка и настройка Jest.
4. Установка и настройка Testing Library.
5. Тестирование компонента с помощью Testing Library:
   
   1. Используя стандартные возможности.
   2. С помощью кастомного рендера.
   3. С помощью кастомных запросов.
6. Тестирование компонента с помощью снимков Jest.

Репозиторий с кодом проекта.

Если вам это интересно, прошу под кат.

SVG-изображения можно вставлять непосредственно в html, можно использовать символьные спрайты, теги <img>, <object> и даже <iframe>. Можно подключать SVG через data-url, css-backgrounds, css-filters и еще множеством способов. Но чтобы полноценно использовать всю суперсилу SVG, необходимо вставлять SVG-изображения непосредственно в html-разметку. Хотя на самом деле есть еще один способ. И он удобный.

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

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

Сегодня я бы хотел с вами поделиться одним из моих любимых паттернов организации сложных react-компонентов, рассказать о его сильных и слабых сторонах (да, некоторые минусы есть). Однако сперва для того, чтобы оценить сильные стороны данного подхода, нужно погрузиться в процесс разработки нового react компонента и сопутствующие ему проблемы, которые подход помогает решить.

Reusability, т. е. повторное использование компонентов ― весьма популярный метод в разработке ПО, веб-сервисов, дизайна и т. п. Огромным преимуществом повторного использования компонентов является экономия средств и времени на разработку ПО. Почему? Если систематизировать повторное использование компонентов, то сокращаются расходы на создание и обслуживание проектов, уменьшаются сроки разработки таких систем, во многих случаях повышается качество программных продуктов. Сегодня предлагаем поговорить об этом методе относительно веб-сайтов, JavaScript и ReactJS.

Если эта тема интересна, то давайте обсудим всё под катом. К слову, статья не очень большая, в ней приводится лишь один пример для Redux, который даёт общее понимание вопроса. А в комментариях давайте обсудим ваш опыт и идеи, которые вы используете в ежедневной работе.

⚛ Джентльменский набор React компонентов FullStack разработчика для управления потоком данных.

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

Благодаря лени узнал, какие фреймворки используют компании на российском рынке. Проанализировал e-comm, банки, интернет-магазины, сайты застройщиков, стриминговые сервисы, телекоммуникации и другие сферы. В конце статьи ссылка на таблицу.

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

В этой статье поговорим о том, как разработать и запустить бэкэнд на Node.js-Express и фронтенд на React в контейнере Docker.

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

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

На самом деле есть другое решение.

Привет, друзья!

Представляю вашему вниманию перевод этой замечательной статьи, посвященной повторному рендерингу (re-render, далее — ререндеринг) в React.

Что такое ререндеринг?

Существует 2 основные стадии, которым следует уделять пристальное внимание, когда речь заходит о производительности в React:

• первоначальный рендеринг (initial rendering) — происходит, когда компонент впервые появляется на экране;
• ререндеринг — второй и последующие рендеринги компонента.

Ререндеринг происходит, когда React необходимо обновить приложение некоторыми данными. Обычно, это является результатом действий пользователя, получения ответа на асинхронный запрос или публикацию при подписке (паттерн "pub/sub" — публикация/подписка или издатель/подписчик) на определенные данные.

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

Патрик Завадски, старший разработчик ПО в компании Northwestern Mutual, подчеркивает, что практики и привычки могут различаться от разработчика к разработчику, от команды к команде и от компании к компании. В любом случае, важно знать разные подходы к написанию кода в React — это хорошее подспорье для программиста в поисках оптимального для него решения.

Под катом — наш перевод статьи*, в которой Патрик сосредоточился на отрицательных примерах: некоторых из худших React-практик, которые он когда-либо видел (а возможно даже использовал сам). Материал призван помочь вам избежать подобных ошибок в будущем.

*Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис.

Мы перешли на шестую версии React-router. Это помогло нам решить несколько проблем, например, определение маршрутов в Switch рендерит точный маршрут, а не первое совпадение, а размер бандла уменьшился в 2 раза.  

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

В этой статье рассмотрим советы и приёмы, которые помогут более профессионально написать код на React.

Практическое руководство по написанию лаконичного кода и повторному использованию вспомогательных функций JS в проектах.

В этой статье я расскажу, как и для чего, на одном из своих проектов, мы прикрутили новую возможность Next.js – On-Demand ISR (инкрементная статическая регенерация по запросу).

Привет, друзья!

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

Предполагается, что вы хорошо знакомы с тем, как работает хук useEffect, а также с тем, когда и почему происходит повторный рендеринг React-компонентов. Если нет, вот парочка ссылок:

• официальная документация по useEffect;
• Продвинутые хуки в React: все о useEffect;
• React: полное руководство по повторному рендерингу.

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

Код проекта, с которым мы будем работать, можно найти здесь.

Начнем с примера.

Привет, меня зовут Кристина, я фронтенд-разработчик в Домклик. Хочу рассказать немного про основные изменения React 18.

Привет, Хабр! Это моя первая публикация и хотелось бы начать с чего-то полезного для сообщества. С места в карьер… Я запилил расширение для VSCode, которое поможет автоматизировать создание файловой структуры компонентов.

Я люблю сталкиваться с трудностями. Но с такими, которые можно решить, подумать над интересным решением, подобрать технологию. Люблю быть в потоке, а после решения чувствую себя настоящим профессионалом.

Но есть кое-что, из-за чего я не люблю программировать. Как ни странно, это тоже трудности, только другого рода. Например, когда, чтобы пофиксить баг, приходится разбираться с легаси-компонентом, который написан на классах на 300 строк кода. Разбираясь уже второй час, ловлю себя на мысли, что уже 10 минут просто смотрю в экран, а в голове «из-за угла» выглядывает мысль «Псс, парень, программирование — это не твое». Такие задачи не вызывают удовлетворения.

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