Vadim Stepanenko

Эта разметка абсолютно правильная в двух случаях:
1) Ваши `close` и `card` действительно нигде не переиспользуются;
2) Объём стилей блока `some-class` остаётся адекватным для восприятия.

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

Возьмём разметку посложнее (не надо в ней искать какого-то смысла, просто от фонаря что-то набрал для иллюстрации):

<div class="block">
  <!-- Header -->
  <div class="block__header">
    <h2 class="block__title">Title</h2>
    <div class="block__actions">
      <button type="button" class="block__action block__action--edit">
        <span class="block__action-icon"></span>
      </button>
    </div>
  </div>
  <!-- Content -->
  <div class="block__content">
    <p>...</p>
  </div>
  <!-- Footer -->
  <div class="block__footer">
    <div class="block__about">
      <div class="block__author"></div>
      <div class="block__date"></div>
    </div>
    <div class="block__awards">
      <div class="block__award">
        <div class="block__award-inner"></div>
        <div class="block__award-tooltip">
          <div class="block__award-tooltip-content"></div>
          <button type="button" class="block__award-tooltip-close"></button>
        </div>
      </div>
    </div>
  </div>
</div>

Положим, что весь контент этого блока уникальный и никак не переиспользуется.
Объём стилей `block` при такой структуре неизбежно станет некомфортным для восприятия, строк на 200-300.

В таком случае хорошо создать внутренний блок (или несколько) просто для того, чтобы размазать сложность.
`block-header`, `block-footer` или даже `block-footer-award`.

Самое главное здесь организовать файловую структуру / конфигурационный файл / чем вы там ещё собираете таким образом, чтобы было очевидно, что `block-footer` - это не самостоятельный блок, а внутренний блок `block`, нужный только для упрощения восприятия, и он не может / не должен использоваться в отрыве от него (в этом случае у него не должно быть в названии общего префикса с `block`, чтобы не создавать путаницу)

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

Ну так и пишите

.element {
   color: var(--color);

   body[theme="dark"] & {
      --color: white;
   }

   body[theme="light"] & {
      --color: #333333;
   }
}

Нет. Тип значения которое уже было возвращено всегда конкретен. Либо это строка, либо это объект.
Можно возвращать объект с методом toString который будет возвращать нужной строку при приведении к строке, но это не равносильно возвращению самой строки.

const ROUTES = {
  blog: {
    art: 'page-art',
    toString() {
      return 'section-blog'
    }
  }
}
ROUTES.blog.art // page-art
ROUTES.blog // object
'text: ' + ROUTES.blog // text: section-blog

Также можно попытаться накостылять магию с прототипом String, но это только в качестве развлечения, на проде за такое руки оторвут.)

SELECT categoryId, COUNT(*) AS `count`
FROM table
GROUP BY categoryId

const index = params?.index ?? section?.index ?? 0;

Перед запуском докера создайте пустой файл и дайте полные права (конечно slow.log а не slow.cfg)

touch ./resources/docker/logs/slow.log
chown 777 ./resources/docker/logs/slow.log

- "./resources/docker/logs/slow.log:/var/log/mysql/mysql-slow.log"

А лучше пробросьте в контейнер всю папку logs

volumes:
      - "./resources/docker/config/my.cfg:/etc/mysql/conf.d/config-file.cnf"
      - "./resources/docker/logs/mysql/:/var/log/mysql/"
      - "./resources/schema/schema.sql:/docker-entrypoint-initdb.d/1-schema.sql"

Это пустые страхи.
Никакой "фрагментации" "диска"в таблице из двух числовых полей (то есть с фиксированным размером записи) не будет. БД прекрасно сама повторно использует ячейки удалённых записей.
Поэтому, как правильно сказал Akina, мягкое удаление для лайков делать бессмысленно

INSERT OR UPDATE

используй INSERT ... ON DUPLICATE KEY UPDATE https://dev.mysql.com/doc/refman/8.0/en/insert-on-...
по user_id тобишь

Схематично:

SELECT orders.column,
       COALESCE(books.column, deposits.column) AS column
FROM orders 
LEFT JOIN books ON orders.type = 'book' AND orders.id = books.order_id
LEFT JOIN deposits ON orders.type = 'deposit' AND orders.id = deposits.order_id

shift+esc:

Обычно items делается в виде объекта, и тогда activeItem = items[activeItemId], это выполняется очень быстро.
Но если надо именно массив, то можно сделать так:

const activeItem = useMemo(() => items.find((item) => item.id === activeItemId), [items, activeItemId]);

Реселект нужен в тех случаях, когда в профайлере видно, что компонент перерисовывается, не смотря на то что данные в компонент не изменились.

Примеры того, когда это может быть: функция внутри useSelector создает и возвращает новый объект/массив. Функция (state) => state.settings[CONST_SECTION].list таковой не является

Даже когда эта идея прозвучала в популярном на то время сериале Теория Большого Взрыва, компания по сбору средств, на такой продукт собрала всего лишь 10 000 долларов что катастрофически мало.

Машина может работать при 35гр? а телефон? вот Вам ответ.
Если ноут перегреется - сам и вырубится, не парьтесь

Конечно нельзя сидеть под прямым солнцем с ЛЮБОЙ техникой(исключения техника с защитой IP 66 и выше). А в беседке - вполне ок, я сижу мне норм)

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

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

Ну на солнце лучше не сидеть. А в помещении при 30 градусах вроде ок.

Из того, без чего жить не могу
1. PhpStorm + sublime
2. Navicat - С этим старичком уже больше 15 лет вместе.
3. Gitkraken \ git-fork
4. Insomnia
5. Vagrant

С докером не локальной машине у меня всегда не складывается. Любое окружение, чуть сложнее запуска 4 контейнеров, сразу же прилетает довесок в виде баш скриптов между ними. Меня это всегда смущает и я перестаю в этом копаться.

Использую следующее:

1. PhpStorm (IDE). Чтобы он работал быстро, проекты следует держать на SSD.
   
2. DBeaver для просмотра содержимого и структуры БД (сами изменения в БД делаю через миграции)
   
3. Postman для того, чтобы дёргать эндпоинты, смотреть ответы и заголовки
   
4. Docker в связке с docker-compose
   

В качестве СУБД обычно использую PostgreSQL, для кеша - Redis. Но это вообще много от чего зависит уже.

Насчёт xampp эо да, тут вопрос идентичности окружения с продом. Вряд-ли то, с чем вы работаете, запускается в проде по виндой.

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