twolegs

В render такое делать нельзя. Место для такой подписки - componentDidMount. Думаю, правильнее будет подписаться один раз, и не делать ничего, если isMenuOpen в true.

if (isMenuOpen) {
      document.addEventListener('keydown', this.keyPressHandler)
    } else {
      document.removeEventListener('keydown', this.keyPressHandler)
    }

Остальное (организация компонент) - это скорее вкусовщина. Но если смотреть в целом - нет какой-то консистентности. Где-то есть компоненты для логических элементов, где-то нет.

Похоже, что вы на windows пытаетесь запустить скрипт, который к этому не приспособлен.
NODE_ICU_DATA - это переменная окружения, попробуйте устанавливать ее через cross-env (https://www.npmjs.com/package/cross-env). Но не уверен. что pwd будет работать даже в этом случае.

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

Что вам больше нравится, принципиальной разницы нет. useQuery более новый способ, Query уже ближе к легаси из предыдущих версий.
С моей точки зрения useQuery удобнее, т.к. в сумме кода получается меньше (нет лишних компонент и монструозных render props).

Данный подход справедлив только к статическим сайтам - где известно точное количество изображений и все они вручную прописаны в файле-библиотеки

Все верно, при использовании изображений как модулей (а при импорте и сборке через вебпак это именно так, изображения по факту становятся js-модулями).

) В реальных проектах - где количество изображений неизвестно и записывать путь к каждой картинке - не лучшее решение. Для этого в state из componentDidMount - ajax запроса будет передан путь к картинке которая храниться на сервере.

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

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

Потому что someText не в корне объекта. Надо доставать state.settingsReducer.someText

Тег image, расположить в координатах (svgWidth - imgWidth) / 2, аналогично для высоты

https://codepen.io/two-legs/pen/OJXrzbW

Как правильно вызывать

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

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

Чтобы можно было использовать импорты без относительных путей, необходимо настроить paths:
https://www.typescriptlang.org/docs/handbook/modul...

Подобное решение не очень удачно, так как вебпак не знает какие ресурсы необходимо скопировать (вы их импортируете динамически).
Возможное решение:
Импортировать все необходимые изображения. Далее вы можете создать словарь, и в коде использовать значения из словаря.

import Img1 from './img1.png';
import Img2 from './img1.png';
import Img3 from './img1.png';

export const images = { Img1, Img2: Img3 }

И при использовании:

import { images } from 'assets.js';

<ImgComponent src={images.Img1} />

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

express-subdomian решает проблему, когда для разных поддоменов необходимы разные роутеры.
Вам достаточно использовать один роутер. Поддомен можно получить например через `req.subdomains`.