Aleksei Podgaev

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

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

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

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

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

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

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

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

вот тут приведён пример кода, позволяющего определить, находтся ли элемент в поле видимости пользователя:
https://stackoverflow.com/a/7557433
Используйте его, чтобы определить когда ваш прогресс бар становится видимым и запускайте анимацию.

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

Судя по всему 3D тут вообще-то не нужен, раз планеты вращать не нужно. Нужно просто грамотно нарисовать полигональные спрайты, которые бы выглядели как 3D. Я бы делал на Phaser (https://phaser.io/) - он гораздо проще и легче, чем Unity. Коллизии, физика - всё что нужно там есть.

Теоретически можно. Но без знаний DOM отрендерить страницу всё равно не получится, а DOM это по сути и есть HTML и CSS. Ну и кроме того без HTML и CSS ваше решение будет очень громоздким, негибким и трудноподдерживаемым. Оно вам нужно?

Если вы не знаете как вставить javascript в html, то я даже не знаю. Может начать с изучения азов? Например как работает тег <script>. JSON это по сути объект Javascript. Т.е. объявляете в javascript переменную и присваиваете ей содержимое этого файла. Только не забудьте потом переделать вашу функцию, чтобы она не запрашивала эти данные с сервера, а использовала значение объявленной переменной.

Если говорить о высокоуровневой архитектуре приложений, то я в последнее время сталкиваюсь с двумя подходами: шина событий (event bus) и flux/redux. В клиентской части популярнее вторая, в серверной - первая (за счёт популярности микросервисной архитектуры). У обоих подходов есть свои плюсы и минусы, серебряной пули нет. Для обоих подходов есть соответствующие библиотеки в документации к которым обычно описаны best practices.
Кроме того, не стоит бояться писать говнокод, особенно для своих проектов. Вы не научитесь писать хороший код, если не будете знать, что такое говнокод. Напишите так, как можете приложение до работающего прототипа, а потом, в следующей итерации, подумайте, как можно сделать лучше. Преждевременная оптимизация - главный враг перфекциониста!
P.S.: забыл добавить, что прямые взаимные зависимости между компонентами - это действительно наихудший подход. Оба описанных подхода преследуют одну цель - избавиться от этих зависимостей.

Я бы рекомендовал воспользоваться имеющимися фреймворками. Чистый MVC на фронтенде уже давно не используется. Но если хочется повозиться с основами, прокачать навыки, то попробуйте мыслить структурно. У вас есть иерархия страница -> хидер -> меню -> элемент меню и т.п. Отражение этой иерархии скорее всего нужно будет реализовать во всех аспектах: модели, контроллерах, вьюхах. Вы должны запустить контроллер страницы, который подготовит модели (запустит их контроллеры) и передаст их во вью страницы. вью страницы, в свою очередь, должен выстроить дерево вью подчинённых и отрендерить их. или вызвать render своих детей, которые в свою очередь вызовут render своих и т.п. как это делает react.

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

На одном домене - могут общаться через localStorage. В вашем примере - не один домен.

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

Что-то подобное, возможно, удастся реализовать если целевой сайт выдаст пользователю не обычную страницу, а pwa. Погуглите на тему progressive web apps - там можно кучу классных штук реализовать, если заморочиться.