20 частых антипаттернов в React и как их исправить: кратко, понятно, без мифов

Стоит отметить, что данные проблемы не надуманны, если вы же сами указывали, что не хватает по большей части глубины + примеры получше, я выше это подтверждал. Как я уже говорил ранее, мало кто изучает изнутри фреймворки, это большая проблема многих разработчиков и проблемы описанные в статье возникают при разработке
Абсурд в целом называть статьи "асболютом", если по факту, это личные практики и наблюдения. Но спасибо, что попытались ее претендовать на это)

20 частых антипаттернов в React и как их исправить: кратко, понятно, без мифов

Благодарю за критику!

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

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

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

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

Ну и как вывод: все мы неидеальны и есть чему учиться у всех.

20 частых антипаттернов в React и как их исправить: кратко, понятно, без мифов

const защищает только переменную от переназначения, но не делает объект неизменяемым: его свойства всё ещё можно изменить.Object.freeze предотвращает изменение самого объекта и его свойств, что важнее для иммутабельности состояния в React. Поэтому просто const — недостаточно, если нужна настоящая неизменяемость объекта)

20 частых антипаттернов в React и как их исправить: кратко, понятно, без мифов

Спасибо большое)

20 частых антипаттернов в React и как их исправить: кратко, понятно, без мифов

Спасибо за хорошее дополнение)

20 частых антипаттернов в React и как их исправить: кратко, понятно, без мифов

Благодарю)

20 частых антипаттернов в React и как их исправить: кратко, понятно, без мифов

Спасибо большое)

20 частых антипаттернов в React и как их исправить: кратко, понятно, без мифов

А, ну тут всё просто на самом деле. Давай на примерах, чтобы стало понятно, где что применять:

1. Константа (вообще не зависит ни от чего)

jsx

const MAX_COUNT = 10; // ← вот это выносим ВНЕ компонента

function Component() {
  return <div>Лимит: {MAX_COUNT}</div>; // всегда 10
}

2. Вычисляемое из пропсов (как в 1-м паттерне)

jsx

function User({firstName, lastName}) {
  const fullName = `${firstName} ${lastName}`; // ← вычисляем на лету
  return <div>{fullName}</div>;
}

3. Состояние (когда нужно "помнить" между рендерами)

jsx

function Counter() {
  const [count, setCount] = useState(0); // ← вот это стейт
  return (
    <button onClick={() => setCount(c => c + 1)}>
      Кликнули {count} раз
    </button>
  );
}

Где твой someValue?

Если someValue:

• Ниоткуда не берётся (константа) → вариант 1

• Считается из пропсов → вариант 2

• Меняется внутри компонента и должен сохраняться → вариант 3

Получается: если значение можно получить прямо сейчас из того, что уже есть (пропсы/другие константы) — не пихай его в стейт. Стейт нужен только для того, что компонент должен "помнить" сам.

Надеюсь подробно описал что да как)

20 частых антипаттернов в React и как их исправить: кратко, понятно, без мифов

1-й пункт:
«Не храни в стейте то, что можно вычислить на лету. Лишние рендеры никому не нужны.»

2-й пункт:
«Если данные должны сохраняться между рендерами (например, состояние формы), обычные переменные не подойдут — только useState или useRef.»

Где противоречие?

• Первый случай — данные уже есть (props), просто комбинируем их.

• Второй случай — данные динамические, и компонент должен их «помнить».

Получается:

• Производные значения → вычисляй прямо в компоненте.

• Настоящее состояние → useState.

Всё, вроде бы, логично, просто контексты разные))