Антон Горецкий

1. Gulp точно не нужен. Мне прям вспомнился 2016 - тогда еще были сборки реакта галпом...
2. В составе create-react-app используется webpack. Нужно просто расширить конфиг с помощью craco.
Вот тутор , который сам для себя проверял на работоспособность: How to Optimize Images for Usage in Websites

Всегда тело запроса ассоциировалось с методом POST

"ассоциировалось".... Чтобы не было "ассоциаций" надо читать доки.

Возможно ли отправлять тело запроса

Достаточно почитать документацию https://www.w3schools.com/tags/ref_httpmethods.asp и станет понятно, что GET-запрос передаёт данные в URL, а не в теле запроса, и есть ограничение на объём передаваемых данных, это очень небольшое значение.

У code review должна быть цель. В моей практике обычно проекты небольшие и там нет отдельных тестировщиков. Получается, что code review отвечает на три вопроса:

1. Соответствует ли функционал ТЗ?
   
2. Создает ли код проблемы команде?
   
3. Есть ли тут какой-то специфичный для проекта опыт, который лучше задокументировать, пока мы еще в контексте?
   

Получается что-то такое:

• До выполнения задачи: проводится анализ задачи, формулируется ТЗ. Бывает, что нужно подключиться и помочь с требованиями, с контекстом, в котором все делается. Чем более подробный анализ мы делаем и чем лучше мы понимаем контекст на этом этапе, тем больше вероятность, что потом весь процесс выполнения задачи пойдет как по маслу и code review будет чистой формальностью в конце.
  
• До ревью: линтеры проверяют код на соответствие стилю, на отсутствие синтаксического бреда.
  
• Дальше - проверка на соответствие функционала ТЗ. Это защита от глупых ошибок в продакшене, которые коснутся пользователей.
  
• Потом - на сответствие принятым соглашениям по коду, если они есть в проекте. Обычно это архитектурные паттерны и что-то про зависимости, смотрим не создает ли код проблем окружающим, а то разные глупости порой случаются. Особенно это важно в коде, который не сам в себе, а затрагивает много чего вокруг. Иногда возникает конфликт интересов, когда что-то явно устарело, и соглашения дополняются чем-то. Чем лучше был анализ в начале, тем меньше вероятность, что тут будет, что обсуждать.
  
• Дальше уточняющие вопросы по странным местам, если они есть. Это больше с целью узнать контекст задачи, почему приняты те или иные решения. Происходит передача специфичных для проекта знаний в сторону команды. Возможно там же будут какие-то рекомендации по поводу практик, на что стоит обратить внимание в следующий раз. Это будет передача опыта от команды.
  

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

Да можно. В коде css выделяете название класса и жмете комбинацию shift+F6 - переименовываете класс и жмете подтверждение (кнопка Refactor) - все вхождения этого класса в верстке будут также переименованы.

Вот тут описан принцип для проводника Windows, делайте аналогично - Как из браузера открыть папку в проводнике Windows

Итак, как раз для прокрутки addEventListener и removeEventListener использовать в реакте вполне легально.
Более того, вы вполне обошли использование рефов используя window, тут все хорошо.
Но вот на следующих граблях - жизненном цикле вы таки споткнулись.
Где гарантия, что компонент не перерендерился и функция disableOnwheel осталось той же что и была ?
Нужно
1) Вынести disableOnwheel за пределы компонентов, там нет ничего что зависело бы от наличия React
2) Внимательно прочесть про клинап https://reactjs.org/docs/hooks-effect.html

В общем, я пока вышел из положения способом, который порекомендовал один из ответивших в этом топике:

const onFocus = (ev: FocusEvent) => {
  (ev.currentTarget as HTMLInputElement)?.removeAttribute('readonly');
};

<input
  ...
  onFocus={onFocus}
  readOnly
 />

То есть все мои инпуты по умолчанию readonly. Это позволяет отсекать автоподсказки при загрузке страницы, но не лишаться их при помещении курсора в поле ввода.

Можно сделать защитников типа:

interface INavDataBase {
  name: string;
  link: string;
}

interface INavDataChilds {
  name: string;
  children: INavDataBase[];
}

type TNavData = INavDataBase | INavDataChilds;

export const navData: TNavData[] = [
  {
    name: "Название меню 1",
    link: "path_to_page",
  },
  {
    name: "Название меню 2",
    children: [
      {
        name: "Название меню 1",
        link: "path_to_page",
      },
      {
        name: "Название меню 2",
        link: "path_to_page",
      },
    ],
  },
];

// Здесь можно по разному проверять и hasOwnProperty или "link" in navData
export const isNavDataBase = (navData: TNavData): navData is INavDataBase =>
  navData.hasOwnProperty("link");

export const isNavDataChilds = (navData: TNavData): navData is INavDataChilds =>
  navData.hasOwnProperty("children");

navData.forEach((data) => {
  if (isNavDataBase(data)) {
    // Здесь будет автокомплит при обращении - data.link
  } else {
    // И здесь, хотя второго защитника мы не использовали - data.children
  }
});

({a, b, c} = {a:1, b:2, c:3 }) // вези меня браузер! Ну если внутри ничего нет то попытаемся

let {a, b, c} = {a:1, b:2, c:3 } // слева переменная, справа значения которые в нее нужно положить. Да Повелитель!

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

Идете в папку C:\Program Files\nodejs\ там находите 4 файла npm.cmd, npm, npx.cmd, npx - открываете их в редакторе и заменяете prefix -g на prefix --location=global Мне это помогло. Если что - вот ссылка на issues в библиотеке npm https://github.com/npm/cli/issues/4980

Лучше фоновое изображение засунуть в svg и сделать маску.
Либо так:
(с пропорциональным увеличением)

либо:
(с фиксированной высотой)

Также с помощью медиа-запросов можно совместить оба эти варианта