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

Вот накидал по быстрому для примера

Этот способ удобен тем, что можно сделать край любой формы, в зависимости от того какой svg использовать. Недостаток в том, что бордер можно только через drop-shadow сделать.

Синхронно это можно сделать так:

var text = 'Привет, мир!';

var u8a = new TextEncoder().encode(text);

var chars = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/';

var bytes = u8a, i, len = bytes.length, base64 = '';

for (i = 0; i < len; i += 3) {
	base64 += chars[bytes[i] >> 2];
	base64 += chars[((bytes[i] & 3) << 4) | (bytes[i + 1] >> 4)];
	base64 += chars[((bytes[i + 1] & 15) << 2) | (bytes[i + 2] >> 6)];
	base64 += chars[bytes[i + 2] & 63];
}

if (len % 3 === 2) {
	base64 = base64.substring(0, base64.length - 1) + '=';
}

else if (len % 3 === 1) {
	base64 = base64.substring(0, base64.length - 2) + '==';
}

console.log(base64);

Асинхронно через FileReader: https://learn.javascript.ru/file#filereader

P. S. Асинхронный способ:

var text = 'Привет, мир!';

var blob = new Blob([ text ]);

var reader = new FileReader();

reader.readAsDataURL(blob);

reader.onload = function() {
	
	var base64 = reader.result.split(',')[1];
	
	console.log(base64);
	
};

Общение обычно происходит через сервис воркер расширения. Из попап шлете сообщение в воркер, а дальше он пересылает в нужную вкладку. Хотя можно сообщение сразу с попапа в нужную вкладку запульнуть, в попап метод tabs доступен.

https://chrome-ext.blogspot.com/2014/02/blog-post_...

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
  }
});