Robur

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

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

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

Правильно - написать параллакс на Реакте.
Но если сильно хочется - то "прямая работа с dom в реакт" и "жизненный цикл компонента".
Вкратце - пишите компонент - обертку, которая рендерит разметку которая нужна вашему параллаксу, когда этот компонент монтируется - получаете созданные dom - элемент(ы), вызываете свой код на этом блоке, он работает, размонтируется - делаете деинициализацию, если нужна.

А чем вас старые в виде dataloader например не устраивают?

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

В общем - применяйте так как можете, со временем поймете больше на практике. А то вам сейчас тут насоветуют git-flow, пул-реквесты самому себе, автоверсионирование, деплой через хуки и прочее вам не нужное.

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

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

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

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

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

потому что у них разные данные на выходе, безотносительно промисов.
В первом случае вернется промис в котором будет результат запроса.
во втором случае вернется промис в котором будет поле 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 его начать писать с большим пониманием.

Как?

1. изучаете программирование. Хотя бы основы
2. изучаете API vk.
3. пишите бота/допиливаете готового
4. в процессе пункта 3 пишите вопросы на тостер
5. бот готов.

Самое главное - не читайте ответы на тостере на этот вопрос.
Это я серьезно.
90% ответов в таких темах - из личного опыта всех тех кто сам не смог. А зачем вам их опыт?

А вот цель для себя найдите, это полезно.

Кратко: Нет.

Длинно:
1. Можно нагородить синтаксического сахара, чтобы получилось например `Item.expandAll()`, но внутри будет то же самое бегание по всем объектам.
2. можно это свойство положить в прототип так что оно будет одно на всех, и будет меняться разом для всех.
Но все Item будут или expand=true или expand=false всегда и смысла в этом как-то немного.

ERR_CONNECTION_REFUSED

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