Aleksei Podgaev

Чтобы чайлд-компонент перерисовывался без перерисовки парента, он должен быть привязан к пропсу не через парента. Например через контекст.
Вынесите waypoints в context, например, и рендерите Checkpoint через Consumer.

Смотря что вы имеете в виду под документацией и как именно организован проект. Как правильно написали выше - самое главное это документировать логику. Как именно это делать зависит от команды - как удобнее. Скорее всего вы придёте к ридми в репозиториях и/или документам в гуглодоках или конфлюэнс.

Если у вас проект настолько разросся, что обзавёлся стайл гайдом и настала пора выносить компоненты в отдельную библиотеку, то можно и эту библиотеку задокументировать. Для этих целей мне лично нравится React Styleguidist. Но вам он может и не подойти. Есть и другие альтернативы, достаточно погуглить и попробовать каждую, чтобы понять какая вам удобнее.

Судя по тексту ошибки, Enzyme не нашёл компонент, на котором вы хотите симулировать коллбэк. Причин может быть две: либо вы опечатались в селекторе, либо имя компонента при рендеринге выглядит не так, как вы думаете. Чтобы найти ошибку, попробуйте вывести в консоль wrapper.debug() и посмотреть как выглядит рендер, возможно найдёте что-то интересное. Ну и в любом случае попробуйте задать компоненту id и искать по нему, это обычно срабатывает.

create-react-app?

я предпочитаю feature-first подход, когда всё относящееся к определённой фиче лежит в отдельной папке. Ситуация описанная вами возникает регулярно, и это тот случай, когда нужно сделать рефакторинг и вынести общую функциональность в некую общую папку, которая будет зависимостью для всех, кто её использует. В этом нет ничего плохого, это общепринятая практика. Главное, чтобы то, что вы выносите в зависимость было самостоятельной сущностью, а не просто одной какой-то переменной или функцией. Логотип - вполне себе отдельная сущность. Набор иконок, анимаций или общих стилевых правил, которыми пользуются другие компоненты - тоже вполне себе отдельная сущность.
В перспективе можно набор общих компонентов вынести в отдельный репозиторий и yarn/npm модуль, но с этим не стоит торопиться.
Другое дело, когда у одной самостоятельной фичи появляется зависимость от другой не связанной с ней прямо фичи - это не всегда хорошо, лучше выносить общий функционал в отдельную фичу, чтобы эти две от неё очевидно зависели.

Что-то я не нашёл во втором компоненте ни импорта формы, ни её использования. Я вижу только импорт formDataProcessing, объявления которого в первом файле нет. Удивительно, как этот код вообще компилируется?

Вопрос решается в два приёма.

Во-первых нужно изучить динамическую подгрузку компонентов, чанки и т.п. вопросы конфигурирования webpack. Можно сделать то же, что делает роутер, но без роутера. ;)

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

Первое, что бросилось в глаза - почему у вас бизнес-логика в экшенах? В папке actions обычно находятся только сами экшены и 'action builder'-ы, на мой взгляд нехорошо, когда один экшен порождает какие-то промисы, реализует какую-то логику и пр. Экшены должны быть просто объявлением, что мы хотим что-то сделать, а логика должна быть в другом месте.
Ну и соглашусь с предыдущими комментаторами. Особенно наличие лишних файлов и папок типа .gitconfig и build в проекте настораживает - даже junior должен понимать основы работы с современными инструментами.

Я бы рекомендовал использовать редакс. Совсем не обязательно сам компонент делать зависимым от редакса. Нужный пропс из состояния может считывать его непосредственный предок.
Если идти без редакса, то придётся, видимо, прокидывать нужный пропс до общего предка. Оба варианта с пробрасыванием методов слишком усложняют проблему, как мне кажется.
Либо сделать какой-то универсальный класс-сервис (так сказать angular-way), который будет хранить состояние этого дропдауна и предоставлять API к нему. Вообще же этот юзкейс довольно специфичный и, если вы хотите создать переиспользуемый компонент, то всё что вам нужно у вас уже есть - можно на этом остановиться. Все эти хитрые варианты использования - проблемы того, кто будет пользоваться компонентом, а не разработчика компонента.

React используется для SSR или только клиент?
Переменная окружения присутствует на сервере, а не в браузере, где исполняется код реакта. Для того, чтобы всё работало, нужно при сборке проекта это учитывать (распарсить код и вставить вместо вызовов переменных их значения). Если вы посмотрите create-react-app - там это уже настроено как надо.

Вот здесь всё описано:

https://jestjs.io/docs/en/timer-mocks

настраиваете моки, потом вызываете jest.runAllTimers(); и смотрите вызвался ли мок

enzyme, который ты судя по всему используешь (jest тут ни при чём) не симулирует браузерные эвенты. он просто вызывает обработчик указанного события, привязанный к найденному элементу. У тебя обработчик привязан к label, поэтому его и нужно искать для запуска simulate. ты же ищешь, как я понимаю, input и пытаешься вызывать simulate у него.

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

Лучше всего вам будет обратиться к одному из готовых starter-pack, в которых вся система сборки (в вашем случае webpack), и тестирования уже настроена и готова к использованию, и посмотреть как там это сделано.

После сборки выполняются e2e тесты, для этого используются инструменты, вроде указанных выше Puppeteer, Protractor, или ещё можно добавить сюда Selenium и Nightwatch.

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

1 - найдите на github какой-нибудь boilerplate, starter или seed app, посмотрите как там всё сделано, разберитесь
2 - погуглите best practices как по структуре react, так и по sass/scss

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