black1277

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

См. книгу Р. Мартин "Чистая архитектура", вот статья об этом на хабре

https://codepen.io/bennettfeely/pen/azJWWX/

document.addEventListener(
  'click',
  (e) => {
    const target = e.target.closest('.media-category__item');
    if (!target) {
      return;
    }
    document.querySelector('.media-category__item.active')?.classList.remove('active');
    target.classList.add('active');
    document.querySelector('.media-tab.active')?.classList.remove('active');
    document.querySelector(`.media-tab[data-tab="${target.dataset.category}"]`)?.classList.add('active');
  },
);

Для контроля изменений DOM используйте MutationObserver. В данном случае вам надо установить опцию childList для слежения за потомками div'а и, если добавление элементов происходит не непосредственно в div, а в его потомка, то ещё и опцию subtree.

Где-то читал, что нехорошо кидаться ошибками изнутри async функций
... надо только возвращать rejected Promise.

В этом `где-то` вас обманули, так как любое возвращаемое из `async` функции значение (да, включая throw) уже обёрнуто в `Promise`.

const foo = async () => { throw new Error('Smth went wrong'); };
const bar = async () => Promise.reject(new Error('Smth went wrong'));

Работают абсолютно одинаково

Для полной коллекции:

decodeURIComponent("\u042d\u0442\u043e \u0442\u0435\u043a\u0441\u0442 \u043a\u043e\u0442\u043e\u0440\u044b \u043d\u0435\u043f\u043e\u043d\u044f\u0442\u043d\u043e\u0439 \u0444\u0438\u0433\u043d\u0451\u0439 \u0437\u0432\u043a\u043e\u0434\u0438\u0440\u043e\u0432\u0430\u043d \u0438 \u0431\u043e\u0433 \u0437\u043d\u0430\u0435\u0442 \u043a\u0430\u043a \u0435\u0433\u043e \u043e\u0431\u0440\u0430\u0442\u043d\u043e \u0441\u0434\u0435\u043b\u0430\u0442\u044c \u043d\u043e\u0440\u043c\u0430\u043b\u044c\u043d\u044b\u043c")

toString() прекрасно сделает работёнку: грязно и дёшево )

(
  "\u042d\u0442\u043e \u0442\u0435\u043a\u0441\u0442 \u043a\u043e\u0442\u043e\u0440\u044b \u043d\u0435\u043f\u043e\u043d\u044f\u0442\u043d\u043e\u0439 \u0444\u0438\u0433\u043d\u0451\u0439 \u0437\u0432\u043a\u043e\u0434\u0438\u0440\u043e\u0432\u0430\u043d \u0438 \u0431\u043e\u0433 \u0437\u043d\u0430\u0435\u0442 \u043a\u0430\u043a \u0435\u0433\u043e \u043e\u0431\u0440\u0430\u0442\u043d\u043e \u0441\u0434\u0435\u043b\u0430\u0442\u044c \u043d\u043e\u0440\u043c\u0430\u043b\u044c\u043d\u044b\u043c"
).toString()  // "Это текст которы ..."

по сути, тут и делать ничего не надо — это просто разные способы записать одну и ту же строку.

Как число можно записать, например, и 1000 и 1e3 и 0x3E8,
так и букву, например, можно записать несколькими способами: "ё", "\u0451".
«В памяти» в итоге окажется одно и то же значение.

Объясняем на простом примере, как в программировании можно использовать логическое мышление.

$description = "<div id='details-2' class='col-12 col-xl-4 col-lg-12 mb-xl-5 mb-5'><div class='d-flex b-skills'><div class='height:70px;'><div class='text-bold'>";
echo $description,"\n";
echo addslashes($description);

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

И откройте уже для себя волшебные клавиши Ctrl-U
При проблемах с генерацией хтмл, надо смотреть ровно то что нагенерил ваш код, а не те красявости, которые старательно подрисовывает к нему инспектор.

Помогло
просто в settings.json нужно написать такой код

"emmet.triggerExpansionOnTab": true,
"files.associations": {"*html": "html"},

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

1. Не умрет
2. Не существует. (продукты касперского я не считаю адекватными)

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

Десятки откликов - это очень мало. Раньше, когда требовалась работа, я отписывал массово на email разным компаниям по вакансиям.
Более сотни откликов, еще и написанных по-разному, чтобы в спам не улетало.
В итоге из сотни откликов нашел пару вариантов для себя. Тоже без опыта. Без вышки. Компаниям на это начхать, если надо вакансию закрыть.
Просто те вакансии, которые ты видишь, они обычно создаются рекрутерами для имитации какой-то своей деятельности. Чтобы показать начальству: "Смотрите, я работаю!" Они и не заинтересованы кого-то там нанимать. Во многих компаниях открытая вакансия идет в счет другому специалисту, который периодически делает типа "за двоих", а потому и деньги себе зачисляет. Такие тоже заинтересованы в отсутствии человека.
И еще момент. На крупных биржах вакансий (не будем тыкать пальцем) многие объявления - фейковые. Никого там не ищут и не отвечают никогда. Вот исходя из этой картины мира и делай выводы.

Никакой религии в этом вопросе нет и быть не может. Есть вполне конкретные правила, когда писать типы весьма полезно.

Если вы НЕ указываете тип, и рассчитываете на автовывод, то значит вам нужен не какой-то конкретный тип, а ТАКОЙ ЖЕ, КАК И... где-то ещё. Например, такой-же-как тип константы или такой-же-как тип возвращаемого значения функции. Иными словами, если я пишу:
const id = findIdByName("abc");
то мне не так важно, какой конкретно тип будет иметь id, мне важно чтобы это был тип возвращаемого значения функции "findIdByName". Для меня это приоритетно. Более того, если в какой-то момент тип возвращаемого значения у этой функции поменяется, то этот код продолжить компилироваться и, вероятно, даже РАБОТАТЬ (это зависит уже от того, что мы потом собираемся делать с id).

Совершенно противоположная ситуация - интерфейсы. В широком смысле. Интерфейсы функций, интерфейсы классов, интерфейсы в смысле типов данных, создаваемых с помощью "interface". Особенно если эту функцию/класс/интерфейс использует много кто ещё. Тогда наоборот, вам НЕЛЬЗЯ допустить, чтобы типы параметров или тип возвращаемого значения просто так поменялись. Это вдвойне важно, если вы пишите библиотеку и речь идёт о её публичном интерфейсе - любое изменение интерфейса тогда должно подкрепляться версионированием (например, семантическим). Вы не можете просто так, тем более по недосмотру, вместо числа начать возвращать из функции строку - вы сломаете ваших клиентов, причём даже не знаете как и где.