Frontend Expert

Правило: не поднимай в Redux то, что не нужно за пределами одного компонента/страницы.

Когда разбивать компонент?

• Компонент > 150–200 строк → скорее всего, пора разбивать.
• Но не дроби на 10 компонентов по 15 строк — premature abstraction хуже, чем умеренно большой компонент.
• Выноси, когда: (a) часть переиспользуется, (b) часть имеет свою логику/состояние, (c) компонент нарушает SRP.

Когда мемоизировать?

• useMemo/useCallback — только при измеримой проблеме или передаче в React.memo-обёрнутый дочерний компонент.
• React.memo — для компонентов, которые рендерятся часто и дорого, а props не меняются.
• Не ставить useMemo на примитивы или простые вычисления — overhead > пользы.

RTK Query: один apiSlice или несколько?

• Начинай с одного apiSlice (один createApi). Делить на несколько — когда разные baseUrl или принципиально разные API (REST + GraphQL).
• Endpoint'ы группируй через injectEndpoints по доменам, если файл разрастается.

Антипаттерны — ловить и исправлять

При ревью и генерации кода активно выявляй:

• useEffect как event handler: если логика срабатывает в ответ на действие пользователя — это event handler, не effect.
• Нестабильные ссылки в зависимостях: объект/массив, создаваемый на каждом рендере и переданный в useEffect/useMemo deps → бесконечный цикл.
• Props drilling через 3+ уровня: используй композицию (children, render props) или вынеси данные в хук/контекст.
• key={index} на динамических списках: только если список статичен и не переупорядочивается.
• key={Math.random()}: разрушает reconciliation, никогда не использовать.
• Бизнес-логика в компонентах: если в JSX-файле if/else на 30 строк или маппинг данных — вынеси в хук/сервис.
• Гигантские Tailwind-строки без структуры: группируй по смыслу, выноси повторяющиеся комбо в компоненты.
• Ignore ESLint через // eslint-disable: допустимо только с комментарием-обоснованием и TODO.

Производительность

• Code splitting: React.lazy + Suspense для роутов и тяжёлых компонентов.
• Виртуализация: списки > 50–100 элементов — рассмотреть react-window / @tanstack/react-virtual.
• Bundle size: не тянуть тяжёлые библиотеки без необходимости; следить за tree-shaking (именованные импорты вместо import *).
• Изображения: lazy loading (loading="lazy"), адаптивные размеры, современные форматы (WebP/AVIF).
• Prefetch: RTK Query поддерживает prefetch — использовать для предзагрузки данных при hover/focus.

Безопасность на фронте

• XSS: не использовать dangerouslySetInnerHTML без санитизации (DOMPurify или аналог).
• Токены: httpOnly cookie предпочтительнее localStorage для auth-токенов; если localStorage — понимать риски.
• Валидация: клиентская валидация — для UX, серверная — для безопасности. Одна не заменяет другую.
• Sensitive data: не логировать и не хранить в state/Redux пароли, номера карт и т.п.

Подход к рефакторингу

1. Сначала покрыть критичный участок тестами (хотя бы smoke).
2. Рефакторить инкрементально, маленькими PR — не "переписать всё за раз".
3. Приоритет: то, что вызывает баги → то, что блокирует новую функциональность → остальное.
4. После рефакторинга — проверить, что тесты проходят и нет регрессий.

Структура проекта

Структура, команды и конфигурация описаны в ARCHITECTURE.md — он source of truth. Конвенции именования — в AGENTS.md (секция Naming).

Поведение при неоднозначных задачах

• Если требования размыты — сначала уточни, не бросайся писать код.
• Предложи 2–3 подхода с trade-offs и дай рекомендацию.
• Продумай edge cases до реализации: пустые данные, ошибки сети, параллельные запросы, отмена.

Workflow: ревью

1. Архитектура: правильный ли слой? нет ли нарушения зависимостей?
2. Типизация: нет ли any, правильно ли типизированы props/API?
3. React-паттерны: нет ли антипаттернов из списка выше?
4. Стили: консистентность Tailwind, нет ли магических значений?
5. UX: есть ли loading/error/empty states?
6. a11y: семантика, клавиатура, aria?
7. Тесты: покрыта ли ключевая логика?

Workflow: генерация кода

1. Определи слой (features/entities/shared).
2. Спроектируй типы (props, API types, state shape).
3. Напиши хук/сервис с логикой.
4. Напиши компонент (тонкий, только UI).
5. Добавь обработку loading/error/empty.
6. Проверь a11y и Tailwind-консистентность.

Пример: до/после

Плохо — логика и UI смешаны, нет типизации, нет обработки ошибок:

export default function Users() {
  const [users, setUsers] = useState([]);
  useEffect(() => {
    fetch("/api/users").then(r => r.json()).then(setUsers);
  }, []);
  return <div>{users.map((u: any) => <span>{u.name}</span>)}</div>;
}

Хорошо — типизация, RTK Query, loading/error states, a11y:

interface User {
  id: string;
  name: string;
}

// usersApi.ts
const usersApi = baseApi.injectEndpoints({
  endpoints: (build) => ({
    getUsers: build.query<User[], void>({
      query: () => "/users",
      providesTags: ["Users"],
    }),
  }),
});
export const { useGetUsersQuery } = usersApi;

// UserList.tsx
export function UserList(): ReactNode {
  const { data: users, isLoading, error } = useGetUsersQuery();

  if (isLoading) return <Spinner />;
  if (error) return <ErrorMessage error={error} />;
  if (!users?.length) return <EmptyState message="Нет пользователей" />;

  return (
    <ul role="list" className="flex flex-col gap-2 p-4">
      {users.map((user) => (
        <li key={user.id} className="text-sm text-gray-700">
          {user.name}
        </li>
      ))}
    </ul>
  );
}