Aleksei Podgaev

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

Я использую всегда второй вариант. Когда начинал намаялся с клиентом от heroku - больше нет желания. Привязка к гиту работает надёжно, можно CI прикрутить при желании.

Если поиграться вот с этим примером (убрать тени например), то можно получить то, что нужно:
https://css-tricks.com/snippets/css/tucked-corners/

делаешь так, что все запросы api должен принимать только при наличии определённого token-а в заголовке. если token отсутствует или неверен отправляешь назад ответ со статусом 401.
этот token клиент и сервер могут получать, например, через переменные окружения (чтобы не светить их в коде)

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.: забыл добавить, что прямые взаимные зависимости между компонентами - это действительно наихудший подход. Оба описанных подхода преследуют одну цель - избавиться от этих зависимостей.

Вообще лучше пользоваться button - это лучше с точки зрения доступности страницы. Разные скринридеры для слабовидящих опираются на разметку при чтении. Ну и вообще, если есть в спецификации кнопка и ссылка, то и нужно их использовать по назначению. Используют div вместо кнопки в некоторых случаях, когда не хотят или не умеют бороться с ненужными в конкретном случае особенностями рендеринга элемента button.

Ответ №1: всё, что только возможно для отображения начального (или какого-то промежуточного) состояния приложения.
Ответ №2: В большинстве применений, с которыми я встречался, серверный рендеринг нужен, чтобы ускорить загрузку начального состояния приложения. При обычном подходе пользователю показывается пустой экран (или индикатор загрузки) до тех пор, пока браузер не скачает все скрипты и шаблоны, не запустит ангуляр, а ангуляр в свою очередь не распарсит шаблоны и не запустит контроллер нужного компонента. При медленном или плохом интернете (например где-то в дороге) или на слабом устройстве, это может занимать довольно много времени. При использовании серверного рендеринга, пользователь получает от сервера готовую страницу с полностью отрендереным начальным состоянием. Т.е. он уже может начать читать какую-то информацию, скроллить или что-то там ещё, не дожидаясь полной загрузки ангуляра. Это делает сайт субъективно для пользователя значительно отзывчивее и быстрее.

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

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

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

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

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

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

https://docs.angularjs.org/guide/unit-testing