abberati

Вы в корне ошибаетесь. Изменение всего стейта произойдёт, да. Но перерисовка всех компонентов — нет. В редаксе селекторы-подписки не вызываются, если не поменялся их кусок стейта. А для более полного контроля есть мемоизированные селекторы. Проверьте сами — гуглить, как в хроме включить flash on painting.

В ошибке написано: «я всё подключил и начал рендерить, но у вас в подключаемых файлах какая-что чушь экспортируется, а не компонент».

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

React-router-dom для работы с историей в браузере. В документации всё написано. Чтобы компоненты не собирались в один бандл, а подтягивались постепенно, нужно заворачивать компоненты в React.lazy, используя динамические импорты. Гуглите и обрящете.

Чтобы это всё работало не только в вебпак-девсервере на локалке, но и на настоящем сервере, нужно сконфигурировать его «по всем роутам кроме файлов отдавать index.html». В интернете много статей, гуглите nginx react spa configuration.

Это обычный глюк дебаггера. Для просмотра доступны переменные, объявленные в лексическом контексте, в котором находится breakpoint.

Первый вариант однозначно лучше, так как родитель теперь не знает про имплементацию детей. Но почему бы вам не инкапсулировать логику внутри Counter в кастомный хук? Он будет использоваться только компонентом Counter, так код будет ещё чище — родитель не знает про имплементацию детей, компонент Counter прост, а внутренняя логика этого компонента описана внутри кастомного хука.

По поводу «сделать лучше»: сделайте две переменных стейта внутри app и передавайте каждому счётчику свои [countN, setCountN] — зачем счётчикам знать про другие счётчики? Тогда внутри счетчика будет меньше кода — нужно обрабатывать данные для конкретно этого счетчика, без необходимости делать setValues({ ...values, })

TL;DR компоненты-классы нужно использовать для создания error boundaries и при ssr. В остальных случаях компонент-функция будет короче и проще.

Если хочешь понять, что могут и чего не могут функциональные компоненты — вот подробное объяснение.

Там написано, что это не для новичков — поэтому нужно на самом деле разбираться, что такое компоненты, как они создаются в виде класса, а как — в виде функции.

Нигде

Для сайд-эффектов (ваш случай это как раз сайд-эффект) должны использоваться middlewares — погуглите redux-saga, эта библиотека вам подойдёт.

Нет, не нужно.

Вы вырвали кусок из контекста статьи. Если отвечать на ваш вопрос без контекста — нет, нежелательно. Нужно разумно распределять стейт по компонентам, использующим этот стейт. Не пробрасывая глубоко внутрь.

Ссылку на статью дайте.