React

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


Что делает useCallback?

Он кэширует функцию, возвращая ту же ссылку, пока зависимости не изменятся.


const handleClick = useCallback(() => {
console.log('Clicked!');
}, []);


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



Где реально нужен useCallback?

- Когда функция передаётся в мемоизированный компонент (React.memo)
- Когда функция используется в useEffect, useMemo или других хук-эффектах
- Когда вы работаете с большими списками, и каждый элемент зависит от onClick или другого хендлера



Где не нужен?

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



Мини-пример


const Parent = () => {
const [count, setCount] = useState(0);

const increment = useCallback(() => {
setCount(c => c + 1);
}, []);

return ;
};

const Child = React.memo(({ onClick }: { onClick: () => void }) => {
console.log('Child rendered');
return Click me;
});


Если бы мы не использовали useCallback, Child бы перерендеривался каждый раз, даже если count не менялся внутри него.


Пишите в комментах, как часто вы используете useCallback — помогает или только мешает?

📲 Мы в MAX

✍️ @React_lib

Сегодня покажу вам, как в React удобно работать с формами на базе react-hook-form. Это мой go-to инструмент для любых форм в проектах.

Почему именно react-hook-form?
- ⚡ Быстрее, чем Formik (нет лишних ререндеров)
- 🔍 Простая валидация через yup или zod
- 🔌 Легко интегрируется с UI-библиотеками (MUI, Ant Design, Tailwind)

Минималистичный пример:

import { useForm } from "react-hook-form";

export default function MyForm() {
const { register, handleSubmit } = useForm();

const onSubmit = data => console.log(data);

return (




);
}


Интеграция с Yup:

import { useForm } from "react-hook-form";
import { yupResolver } from "@hookform/resolvers/yup";
import * as yup from "yup";

const schema = yup.object({
email: yup.string().email().required(),
}).required();

export default function ValidatedForm() {
const { register, handleSubmit, formState: { errors } } = useForm({
resolver: yupResolver(schema),
});

return (
console.log(data))}>

{errors.email?.message}
Отправить

);
}


🔥 Очень советую попробовать на новом проекте. Работать с формами становится не только проще, но и приятно.

📲 Мы в MAX

✍️ @React_lib

Как сделать loader с задержкой, чтобы не мигал?

Иногда при загрузке данных хочется показать спиннер, но только если это занимает больше, скажем, 300мс. Это позволяет избежать "мигающего" лоадера при быстрой загрузке. Я часто использую этот приём, особенно при загрузке модалок или переключении вкладок.

Вот простая реализация на React:


import { useState, useEffect } from "react";

function useDelayedLoader(isLoading: boolean, delay = 300) {
const [showLoader, setShowLoader] = useState(false);

useEffect(() => {
let timeout: ReturnType;

if (isLoading) {
timeout = setTimeout(() => setShowLoader(true), delay);
} else {
setShowLoader(false);
}

return () => clearTimeout(timeout);
}, [isLoading, delay]);

return showLoader;
}


Использование:


const isLoading = ...; // например, из useQuery или useState
const showLoader = useDelayedLoader(isLoading);

return (

{showLoader && }
{!isLoading && }

);


⚡️ Профит — спиннер появляется только если загрузка реально долгая. Пользователь не чувствует "дёргания" интерфейса. Маленький UX-трюк, но эффект — огромный.


📲 Мы в MAX

✍️ @React_lib

Сегодня написал пост на тему, которая регулярно бьёт по скорости разработки: почему React-приложение “тормозит”, даже когда кажется, что код нормальный.

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

Обычно проблема не в React как таковом. Проблема в том, что мы слишком поздно начинаем смотреть что именно ререндерится.

Вот 3 вещи, которые я первым делом проверяю:

1. Родитель слишком “шумный”
Если родительский компонент часто обновляет state, все дочерние компоненты тоже могут улетать в ререндер.
Даже если визуально ничего не меняется.

2. useMemo и useCallback не спасают автоматически
Их часто добавляют “на всякий случай”, но без понимания, где узкое место.
В итоге код становится сложнее, а пользы - ноль.

3. Ключи в списках
Нестабильные key - классика.
Если в списке стоит index, React может пересоздавать элементы там, где не должен.
Особенно больно это ощущается в интерактивных списках.

Мой рабочий подход простой:

• сначала открываю React DevTools Profiler
• нахожу, какой компонент ререндерится чаще всего
• проверяю, это реально нужно или нет
• только потом оптимизирую

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

📲 Мы в MAX

✍️ @React_lib

⚛️ Реактивность - это просто (и всего 35 строк кода)

Мы часто воспринимаем реактивность в современных фреймворках (Vue, Solid, MobX или Preact Signals) как некую "магию". Кажется, что под капотом там сложные механизмы, доступные только избранным архитекторам.

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

В статье «Reactivity is easy» он разбирает ключевые концепции:
🔹 Signals (Сигналы) — контейнеры для значений.
🔹 Effects (Эффекты) — функции, которые реагируют на изменения.
🔹 Dependency Tracking — как именно эффект "узнает", на какие сигналы он подписан (спойлер: через глобальный контекст).

Отличный материал для тех, кто хочет перестать бояться "магии" стейт-менеджеров и понять, как всё работает на уровне чистого JS.

👉 Читать статью: https://romgrk.com/posts/reactivity-is-easy

#js #frontend #reactivity #architecture

📲 Мы в MAX

✍️ @React_lib

🚀 Что такое условный рендеринг в React и зачем он нужен?

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

Думайте об этом как о "if... else...", но для вашего пользовательского интерфейса (UI).


- ЕСЛИ пользователь вошел в систему, ТО показать компонент .

- ИНАЧЕ показать компонент .


💡 Для чего он нужен?

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

Он нужен буквально повсюду. Вот самые частые примеры:

- Пока идет загрузка данных с сервера: Мы показываем (крутилку). Как только данные пришли — показываем .

- Аутентификация: Показываем "Профиль", если isLoggedIn === true, и "Войти", если isLoggedIn === false.

- Обработка ошибок: Если при загрузке произошла ошибка, мы показываем вместо контента.

- Пустые состояния: Показываем "Ваша корзина пуста", если cart.items.length === 0, и список товаров, если в ней что-то есть.

- Интерактив: Показ/скрытие модальных окон, выпадающих меню или вкладок по клику.


🛠️ Как это сделать?

В React есть несколько популярных способов:

1. Тернарный оператор (? :) - самый частый выбор.
{isLoading ? : }

2. Логический оператор "И" (&&) - идеален, когда вам нужно что-то показать или не показать ничего (нет ветки "else").
{hasMessages && }

3. Обычный if/else - используется внутри тела компонента, до return, для более сложной логики.

Условный рендеринг - это не просто "фича", это сам смысл React. Это то, что позволяет вашему UI реагировать на изменения данных и действия пользователя.

#React #JavaScript #Frontend #Development #ConditionalRendering

📲 Мы в MAX

✍️ @React_lib

Кастомные хуки (Custom Hooks). Создаем свой первый кастомный хук useWindowSize

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

Мы создадим функцию, которая:

1. Использует useState для хранения размеров.
2. Использует useEffect для подписки на событие resize.
3. Важно: Не забываем удалять обработчик событий (cleanup function), чтобы не нагружать память!


Вот готовый пример. Можете сохранить его в файл useWindowSize.js.


import { useState, useEffect } from 'react';

// Наш кастомный хук
function useWindowSize() {
// 1. Инициализируем состояние
const [windowSize, setWindowSize] = useState({
width: undefined,
height: undefined,
});

useEffect(() => {
// Функция для обновления состояния
function handleResize() {
setWindowSize({
width: window.innerWidth,
height: window.innerHeight,
});
}

// Устанавливаем размер сразу при загрузке
handleResize();

// 2. Добавляем слушатель события изменения размера окна
window.addEventListener("resize", handleResize);

// 3. Очистка: удаляем слушатель при размонтировании
return () => window.removeEventListener("resize", handleResize);
}, []); // Пустой массив зависимостей = запускаем один раз

return windowSize;
}

export default useWindowSize;


🚀 Как это использовать в компоненте?

Теперь ваш компонент становится чистым и понятным. Никакой лишней логики внутри!


import React from 'react';
import useWindowSize from './useWindowSize';

const App = () => {
// Просто вызываем наш хук
const { width, height } = useWindowSize();

return (

📏 Размер окна
Ширина: {width}px
Высота: {height}px

{width < 600 ? (
📱 Похоже, вы на мобильном устройстве!
) : (
💻 Это десктопная версия.
)}

);
};

export default App;

📲 Мы в MAX

✍️ @React_lib

🎯 Сегодня покажу вам простой, но мощный приём: как ускорить React-приложение с помощью мемоизации списков

Каждый из нас рендерит списки: товары, заявки, комментарии, юзеров - список бесконечен.
И одна из самых частых проблем: каждый элемент списка перерендеривается даже при минимальном изменении родителя.

Сегодня разбираем реальный кейс и решение, которое спасает производительность.

🔥 Проблема

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

Причина проста: у каждого элемента меняется ссылка на props → компонент считается обновлённым → React перерендеривает его.


💡 Решение: React.memo + useCallback

Вот минимальный рабочий пример.

Компонент элемента списка


const TaskItem = React.memo(function TaskItem({ task, onToggle }) {
console.log("Render:", task.title);
return (

onToggle(task.id)}
/>
{task.title}

);
});


Родитель


function TaskList() {
const [tasks, setTasks] = useState(data);

const toggle = useCallback(id => {
setTasks(prev =>
prev.map(t => (t.id === id ? { ...t, done: !t.done } : t))
);
}, []);

return tasks.map(task => (

));
}



🚀 Что это даёт?

- React.memo не даст компоненту перерендериться без изменения реальных данных.
- useCallback создаёт стабильную ссылку на функцию.
- Итог: перерендерятся только изменённые элементы, остальное остаётся нетронутым.

При 500+ элементах разница ощущается моментально.

📲 Мы в MAX

✍️ @React_lib

🧠 Сегодня я покажу вам трюк, который ускоряет ре-рендеры в React на реальных проектах

Иногда компонент начинает перерендериваться слишком часто, даже когда его пропсы не меняются. Особенно это заметно в списках, формах и сложных UI.
Сегодня я расскажу, как я на проектах использую мемоизацию коллбеков и данных, чтобы UI перестал «дергаться».

🔥 Проблема

Допустим, есть список элементов, и каждый элемент получает проп onSelect, который создаётся при каждом рендере родителя:


const handleSelect = id => {
setSelected(id);
};


Каждый раз новая функция → дочерние элементы думают, что проп изменился → ненужный ререндер.

✅ Решение

Используйте useCallback:


const handleSelect = useCallback((id) => {
setSelected(id);
}, []);


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

🎯 Практическое правило, которое я использую

Мемоизируйте только то, что реально ререндерится слишком часто.
Слепая мемоизация = грязный код.

📲 Мы в MAX

✍️ @React_lib

Почему useEffect - это не костыль, а инструмент, и как им не надо пользоваться 😅

Очень часто вижу в коде:


useEffect(() => {
fetchData();
}, []);


и всё вроде бы ок… пока не появляется зависимость, вроде userId, и кто-то лениво добавляет её в массив зависимостей, не понимая, что произойдёт при каждом изменении.

👉 Проблема не в useEffect - а в том, что мы не до конца понимаем его модель.
useEffect = реакция на изменение состояния.
Если у тебя эффект, который не зависит от UI - например, загрузка данных - вынеси его в кастомный хук или вообще за пределы компонента.

Например:


function useUser(userId) {
const [user, setUser] = useState(null);

useEffect(() => {
let ignore = false;
async function load() {
const data = await fetch(`/api/user/${userId}`).then(r => r.json());
if (!ignore) setUser(data);
}
load();
return () => (ignore = true);
}, [userId]);

return user;
}


Теперь у тебя эффект чистый, изолированный и переиспользуемый.
Компонент не знает ничего про загрузку - он просто получает user.

💡 Маленький лайфхак: если ты пишешь эффект и не можешь объяснить словами, почему он зависит от этих переменных - скорее всего, архитектура требует пересмотра, а не новый костыль в useEffect.

📲 Мы в MAX

✍️ @React_lib