Robur

https://reactjs.org/docs/code-splitting.html тут все подробнейшим образом разжевано. Подробнее рассказать сложно

скорее всего вам будет достаточно такого:

var data = {};
var get = "key1";
data[get] = 1;

Почему первый вариант использования работает , а второй вариант - нет.

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

например, в первом случае в данных будет `{data: {x:1}}` а во втором `{x:1}`

очевидно что разные данные приведут к разным результатам.

Промис там или не промис - дело десятое, в плане промисов оба варианта идентичны.

Компоненты в Реакте делятся на несколько основных групп (напишите где ошибаюсь):

Ошибаетесь в том что в реакте компоненты делятся на какие-то такие группы. В реакте компоненты делятся совсем по другому - функциональные, на основе классов и так далее.

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

Update from 2019: I wrote this article a long time ago and my views have since evolved. In particular, I don’t suggest splitting your components like this anymore.

Можно выбрать и какой-то другой подход. И делить по другому. Или вообще на других принципах строить архитектуру. Или видоизменить его подход под какие-то свои конкретные нужны и так далее.

поэтому ответ на вопрос:

Если мы хотим чтобы шапка была серая, куда писать этот стиль?

Зависит от того - как вы в итоге строите свое приложение.
Поэтому ответ - как вы сами считаете правильным.
Для меня критейрий прост - если вы решили делать вещи каким-то образом и через время, когда вам нужно что-то сделать в этом коде вы материтесь и страдаете - решение было неверным. надо делать по другому. Если же меняете то что нужно достаточно легко и без проблем - вы все сделали правильно.

Когда приложение достаточно вырастет - вы сами поймете как для вас лучше, если будете обращать внимание.

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

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

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

Все состояния не нужно.

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

UI просто может отображать эти состояния каким-то образом, так же как он отображает данные когда они в сторе появляются.

Все что нужно понимать про прототипы, классы, наследование и ООП в JS:
1. свойство prototype это ссылка на объект на который будет указывать __proto__ после вызова new.
2. в любом объекте в JS при поиска поля если его нет в самом объекте, он будет искаться в объекте на который указывает __proto__

Object.freeze на все подряд вам поможет.

Это нормальный подход, можно просто Promise.all

В драйвере/библиотеке есть пул соединений, и он влияет на то как оно все будет работать, если у вас пул на 5 соединений, то даже если вы запустите 100 запросов параллельно, в реальности будут выполняться первые 5, потом еще 5, потом еще 5.

Если вы хотите прямо в один запрос завернуть что-то большее чем обычный find, то возможно вам будут полезны агрегаты https://docs.mongodb.com/manual/aggregation/

У вас ширина контейнера зависит от того свернули вы его или нет.
Получается так:
- длинное меню
- поменяли размер экрана. контейнер не влез, свернули меню
- меню короткое
- поменяли размер экрана еще раз. Контейнер свернут - отлично влезает, разворачиваем.
- длинное меню
- повторяем все сначала

соответственно при каждом следующем вызове mobileMenu он то сворачивается то разворачивается.

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

Для фокуса сделайте свои css- классы. И их же для скрытия/показа.
Ловите события мыши на меню - ховер, клик, работаете с дом элементами добавляя/удаляя эти классы как вам нужно.

Вам надо просто при переходе с registration на login не добавить а заменить роут

было: /main -> /solvation -> /registration
переходите на /login, становится: /main -> /solvation -> /login

в этом случае все работает как надо автомагически.

Заменить роут - смотря как вы его реализовали, если через то https://reacttraining.com/react-router/web/api/Lin...

Можно и в императивном стиле писать как в школе на паскале учили - и тоже будет "хватать".

Так как вы - можно писать, на govnocod.ru это конечно не тянет. Так же "на прототипах" есть еще 50 вариантов как сделать то же самое.

Но есть варианты лучше - чище код, легче поддерживается, лучше intellisense, разные разработчики пишут одинаково, разработка быстрее, компилятор/сборщик лучше оптимизируют и прочие бонусы.

Вопрос стоит поставить так: по какой причине вы все еще пишете тот вариант у которого объективно больше недостатков?
Я знаю только одну - лень/некогда/нежелание разобраться в новых возможностях и переучиться. Она не очень весомая.

нормальное.
Удачи вам в яваскрипте с таким перфекционизмом.