Павел Антонов

или с jquery

Использовать @font-face и настроить webpack-file-loader для файлов шрифтов.
Нет принципиальной разницы будете вы при этом использовать injectGlobal или импорт scss/css файла.

Концепция модулей как способа организации JavaScript-кода

Что такое модуль?
Модуль — это переиспользуемая часть кода, содержащая в себе детали реализации и предоставляющая открытое API, что позволяет легко загрузить её и использовать в другом коде.

Технически код можно написать и без использования модулей. Модули — это паттерн, который в разных формах и на разных языках используется разработчиками с 60-х и 70-х годов.
В идеале, модули JavaScript позволяют нам:

• абстрагировать код, передавая функциональные возможности сторонним библиотекам, так что нам не придётся разбираться во всех сложностях их реализации;
  
• инкапсулировать код, скрывая его внутри модуля, если не хотим, чтобы его изменяли;
  
• переиспользовать код, избавляясь от необходимости писать одно и то же снова и снова;
  
• управлять зависмостями, легко изменяя зависимости без необходимости переписывать наш код.
  

tproger
или
learn.javascript.ru

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

В идеале было бы собрать пример в песочнице, в jsfiddle или codepen или plnkr. Тогда его можно за минутку подправить, и все.

Попробуй внятно описать словами что ты вообще пытаешься сделать. Сейчас выглядит довольно странновато, учитывая что в css есть псевдоселектор :focus

background-size: cover;
htmlbook.ru/css/background-size

• Можно вынести эту папку в отдельный репозиторий и подключать как модуль git
  
• Можно запустить локальный npm-репозиторий и публиковать туда эту библиотеку компонентов
  

Выполните в консоли monitorEvents(document.body); Увидите все события по мере их появления. Если надо фильтровать - второй аргумент для этой функции: monitorEvents(document.body, 'click'); - покажет все клики.

Принцип KISS не означает что надо использовать самые примитивные инструменты.
Он означает, что не надо переусложнять систему без нужды.
Если так рассуждать, так и высшее образование не нужно: "Дед отличные бани строил, хотя вовсе был неграмотный. Я и без сопромата небоскреб построю!"
Если вы пока ещё не понимаете назначение всех этих "лееров, провайдеров и репозиториев", это не значит, что они вообще никому не нужны.

Для того, чтобы упростить управление системой, её надо усложнить.
Этот принцип относится к любой области человеческой деятельности, от постройки ракет до управления государствами.
Чем сложнее система, тем больше накладные расходы на ее управление. Хоумпейдж с котиками можно и нужно делать примитивными средствами. В большом проекте надо сразу закладываться на будущую расширяемость. То есть, заранее делить ответственность между "леерами".

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

1. Перерисовка компонента происходит, как следствие перерисовки родителя или вызовов this.setState() или this.forceUpdate().
Ее можно контролировать в class components с помощью метода жизненного цикла shouldComponentUpdate. При вызове this.forceUpdate() shouldComponentUpdate не вызывается.

2.

Изменение свойств (props) компонента, полученных от родителя или перерисовка родителя.

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

Чтобы дочерние компоненты не перерисовывались по цепочке, вы должны реализовывать метод shouldComponentUpdate или использовать PureComponent там, где это уместно. Перерисовку функциональных компонентов контролировать нельзя(разве с помощью HOC). Использование HOC connect убирает все лишние перерисовки дочернего компонента.

3. Провайдеры это обычные компоненты. Перерисовывается родитель - перерисовываются они.

Все, что я написал выше, кроме кейса с connect, есть в официальной документации. Стоит открыть почитать.

Примените инлайново стиль visibility: hidden для блока, а потом в том же JS примените стиль visibility: visible для скрытого блока

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

Хороший кандидат на должность Junior React Developer, по моему мнению, должен соответствовать следующему перечню требований:
1. Хорошее знание JavaScript. В React разработке используется ES6 и большинство экспериментальных фич еще не вошедших в стандарт.
2. Хорошее знание HTML и CSS. Кроссбраузерная верстка. Так же, хорошо иметь представление о том, что такое css-in-js.
3. Web APIs. Умение работать с объектной моделью документа(DOM) и все эти XMLHttpRequest, localstorage, cookie, history и прочее.
4. Хорошее знание API React. Вы должны хорошо знать React, знать его возможности, понимать основные концепции и уметь ответить на большинство типовых вопросов. Для этого достаточно хорошо изучить документацию, разобрать пару типовых проектов на github и попрактиковаться. Много полезной информации, приёмов и идей можно подчерпнуть из тематических статей и докладов. Так же, на просторах интернета можно найти подборки типовых вопросов, часто задаваемых на собеседованиях. В англоязычном сегменте их больше.
5. Redux. Уверенное знание API. API библиотеки до боли пост. Знать, что такое промежуточное ПО и зачем оно. Понимать базовые концепции архитектуры Flux. Все это есть в документации и многочисленных курсах.
6. Умение работать с менеджером пакетов npm на базовом уровне.
7. Node.js. Хотя бы уметь написать простейший express/koa сервер, который будет отдавать ваше приложение и статику.
8. Webpack. Базовые знания.
9. Умение работать с git. Хотя бы знать и уметь примерять команды: init, clone, add, commit, push, pull, merge, checkout.
10. Иммутабельность. Четкое понимание зачем это надо. Знание приемов иммутабельного изменения структур данных. Это есть в официальном туториале React.
11. Статическая типизация TypeScrpt/Flow. Для начала хватит самых основ и способности понимать чужой код.
12. Функциональное программирование. Хватит знаний полученных в процессе изучения JavaScript, а так же не помешает знать, что такое каррирование, чистые функции и рекурсия.
13. Базовые концепции ООП. Хватит знаний полученных в рамках изучения JavaScript.
14. Асинхронный код. Понимать как его правильно организовывать. Promise, async/await.
15. Сетевые протоколы передачи данных. Вполне хватит базовых знаний о http/https, о том, что такое заголовки и какие они бывают. Хорошо знать о том, что такое websocket.
16. За плечами должен быть хотя бы один учебный проект на React. Хватит типового тестового задания.
Примеры таких заданий: 1, 2, 3(сайт может быть не доступен на территории РФ, советую отрыть через VPN и посмотреть), 4, 5. Если подобного проекта у вас нет, то будьте готовы, что потенциальный работодатель предложит вам выполнить тестовое задание и только по его результату вас, может быть, пригласят на техническое интервью. Если напишите хорошо, вас скорей всего пригласят.
17. Желателен опыт создания типовых UI элементов. Например, чтобы не вызывало трудностей написать простой кастомный чекбокс. Куча примеров реализаций типовых элементов есть на codepen.

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

Похожий вопрос.