ReactLover

Я вас расстрою, но это риск, который просто придётся принять. Для ИПшника шанс выиграть суд у западной компании, не имеющей представительства в РФ, исчезающе мал.

*:focus {
    -webkit-tap-highlight-color: transparent;
    outline: none;
    -ms-touch-action: manipulation;
    touch-action: manipulation;
}

На винде запускать - это бред.
Если на VPS планируете держать только бота, то лучше оформить его в виде пакета. Настройте CI\CD и он сам будет развёртываться на вашем сервере прикаждом релизе в системе контроля версий.
Лично я разворачиваю бота в докере, потому что боту обычно нужна БД, какие-то приложения рядом... Всё установть и настроить - это отдельная история и спустя пару лет бесперебойной работы вам или вашему заказчику, возможно, придётся переехать на другой хостинг или переустановить и настроить все заново, а из памяти всё уже выветрилось. Спасает описание всей конфигурации в виде docker-compose.
Тогда переезд на ноый сервер вообще тривиален. Также легко поднять тестовый клон бота на локальной машине для отладки и работать он будет в той же среде и с той же конфигурацией, что и на сервере.
Особенно это удобно, если приходится приментяь какие-то конвертеры графики или звука.

Если надо поднять дв абота на разных фреймворках или с разными зависимостями, то докеризация тоже спасает от необходимости возиться с venv. А зависимости бывают еще и у сторонних внешних утлит.

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

Докер - это не виртуалка, а контейнер приложения.

Остальное выглядит как размышление о поставленной задаче в пустоту.

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

Ну это ваши личные проблемы. Работа это не школа не институт и не курсы. На работе заказчик платит за то, что хочет заказчик, а не за то, что хочет разработчик.

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

Этот вопрос совершенно не нужен в интернет. Спрашивай своего тимлида. Не во всех проектах есть "нормальные задачи", как ты их считаешь. Где-то ведь продукт уже написан, им пользуются люди, и в нем не нужно ничего дорабатывать. Просто обслуживать - решать проблемы эксплуатации, возможно подправлять баги, возможно обновлять что-то, чтобы продукт запускался на более новой версии java или оборудовании.
И это НОРМАЛЬНО. С точки зрения пользователя, тебе было бы интересно купить машину, а потом платить каждый месяц еще 10% ее стоимости за то, что в ней каждый месяц то форма дверей меняется то диаметр колес то еще что-то? Думаю нет, ты бы хотел купить машину один раз и не лазить под капот несколько лет.

При этот мой же куратор объяснил, что большая часть задач подобного рода, но его опыт и его задачи говорят о том, что всё же есть и много нормальных задач как и с использованием ASP.NET, реализацией API, структурой самой веб-системы и прочего.

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

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

В чистом prettier - нет. В нём специально ограничен функционал, чтоб кашу не получить.

P.S. Не понимаю я таких как ты удаляторов. Шанс получить косяк типа:

console.log('some')


// iterate
[1, 2, 3].forEach(func)

вообще не стоит экономии на спичках.

Судя по описанию у вас команда в целом не понимает что делать и как. А то что делают, делают неправильно.
Стоит начать с того, чтобы найти хорошего лида. Тогда все вопросы о том, кто и что должен делать, и в какой последовательности отпадут сами собой.

API разрабатывает бэк, но не по дизайну, а по аналитике от ТЗ.
Если есть только дизайн, то всё равно надо посадить аналитика который по пунктам распишет весь функционал. Иначе будет сказка про лебедя, рака и щуку. Страшная.

Далее разработка выглядит примерно так:

Параллельно:
Фронт начинает пилить визуальную часть без привязки к бэку.
Бэк исходя из аналитики думает архитектуру и кидает примерный json(а не точный свагер, лишняя трата времени).

Совместно:
Фронт смотрит этот json и если видит, что чего-то не хватает - запускает обсуждение с бэком.

Параллельно:
Бэк пилит по очереди сервисы\эндпоинты с автогенерацией свагера из кода.
Фронт пилит на основе простых json-моков из предыдущего шага и по готовности подключает эндпоинты с автогенерацией клиента из свагера.

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

P.S. Привязывать API к UI - безумие. UI - это мимолётная штука, как сумочка у дамы. Сегодня одна, завтра другая. API же опирается на архитектуру приложения, от которой зависит всё: и бизнес-логика, и тупо скорость работы, и многое другое.

Многие фронтендеры относятся к беку, как к некой обертке для работы с базой данной. Когда такие становится лидом команды и начинают диктовать свои требования беку, начинается ад, проект даже с простым беком превращается в нечто монструозное, разваливающиеся на ходу. Но, так как снаружи бек не виден, руководство считает, что дело в отдельных тупых бек-разработчиках, которые артачатся, не хотят работать и увольняются.
Судя по вашим фразам, вы скорее всего один из них. Так как уверены, что приложение - это то, что на фронте, что api - это хрень, которая завязана на отображении информации на фронте, что разработчики бека не нужны при разработке архитектуры и вообще пофиг, что они там делают, главное чтобы давали то, что хочет фронт.
Но, раз вопрос задан, значит сомнения вас посещают. Поэтому: приложение это не только фронт, а зачастую фронт это не самая сложная его часть. Бек - это не обертка над базой данных, и если вы поменяете значение в базе, это не значит, что к примеру, в потоковом вещании сменится кодек (вот, кому-то может и смешно, а мне в такой ситуации ни фига не было весело). С помощью API получают данные, поэтому не важно, что там у вас напроектировали дизайнеры, или как эти данные выводит фронт, API должен быть универсальным и не зависить от того как вы отображаете данные, поэтому, к примеру, бек может вам дать для получения данных несколько универсальных запросов, а не один специальный. В общем, все гораздо сложнее, и ваш вопрос как состыковать фронт и бек перерастает в вопрос как формировать архитектуру проекта, и как управлять командой.

Не стоит. Стоит верстать очень близко к макету, но задрачиваться по поводу 1px вправо-влево точно не стоит. Вообще, pixel perfect как концепция старше адаптивной верстки. И в случае адаптива теряет всякий смысл.

Никакой, план безопасности определяет пользователь.

Никак. Всё, что ушло клиенту может быть изменено им.

Например у ВК vk.com при попытке изменить стили/удалить элементы и прочие манипуляции ничего не дают

С чего вы это взяли? Легко меняется как текст, так и стили.

Если нельзя обновить ядро средствами бубунты - то как обычно - скачать исходники, собрать и поставить. Манов по самостоятельной сборке и установке ядра - хоть #опой жуй.

Перепиши кастомный хук таким образом, чтобы он возвращал постоянную функцию. Да, с тем же useCallback. Если этот хук не зависит от пропсов/стейта, то очевидно, функция должна быть постоянной.

Если ты шаришь в теме - посмотри последние коммиты и всё ясно станет.
Если ты эффективный менеджер - иди нафиг.