Aleksei Podgaev

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

Ни в коем случае не начинайте использовать селениум! Это сплошные тормоза и глюки. Возьмите лучше упомянутый выше Cypress. Он не глючит и шустрее и тесты для него пишутся на JS с привычным синтаксисом как в Jest/Mocha.

Автоматический запуск с уведомлением на почту у нас реализован через Jenkins.

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

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

Зависит от деталей, но в общем случае - первый вариант, да. Нужно замокать входные данные, замокать ожидаемые выходные и так тестировать. Но это не значит, что более мелкие внутренние функции тестировать не нужно.

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

create-react-app?

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

Просто так на коленке рассчитать невозможно. Даже такие гиганты как EVE Online имеют выделенных специалистов для этого. Один из них впоследствии стал министром финансов Греции. И даже несмотря на это они всё время перебалансируют экономику и пытаются всеми силами тормозить инфляцию, которая неизбежна.

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

Самое главное это чтобы количество денег появляющихся в игре из ниоткуда (добыча ресурсов, дроп с монстров и т.п.) уравновешивалось количеством денег исчезающих из игры (разрушение, износ предметов и т.п.).

Начните с балансировки какой-то одной цепочки, потом втянитесь и начнёте лучше понимать как остальное сбалансировать.

Ответ: запретить сохранение нельзя никак.
Комментарий: Зачем вам это нужно? Если вы боитесь, что заказчик сбежит не заплатив - на это есть авторское право, по умолчанию вы владеете всеми правами на ваш труд. Если заказчик не подписал акт приёмки - сайт ваш, если он попытается его без вас поднять где-то - подаёте на него в суд и доказываете в суде, что исходники были созданы вами. Он тогда не только за работу вам заплатит, но и компенсацию вреда. То же самое касается и других разработчиков. Если вы не опубликовали ваши скрипты под открытой (open source) лицензией, то их нельзя без вашего ведома использовать.

Вы немножко путаете понятия. Организация кода и наследование - это разные вещи.
Наследование, безусловно, должно использоваться, там где оно необходимо, безотносительно того, как организован код.
Я в последнее время сколняюсь к подходу feature-first architecture. Это позволяет легко модифицировать разные участки кода несколькими разработчиками одновременно не мешая друг другу. Проблема при этом - правильно выделить, что является фичей. И зависимости между фичами нужно тщательно продумывать, кто от кого зависит.

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

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

Так и чем каждый раз занят порт? Может быть можно не запускать тот второй сервер на время разработки?

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

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

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

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

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

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

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

Две относительно затратные операции, о которых часто забывают - console.log (и вообще вывод куда-либо) и JSON.parse/stringify - посмотрите не часто ли вы ими пользуетесь. Особенно парсинг JSON можно хорошо оптимизировать, если подумать, где и как используется результат.

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

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

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