Алексей Николаев

Ответ на вопрос "почему" заключается в одной емкой фразе: потому что сложно синхронизировать интерфейс и состояние.

Представьте, что у вас есть простой UI какого-нибудь ToDoApp. Вам всего-то нужно сделать так, чтобы при вводе новой задачи она появлялась в списке, а при нажатии на крестик напротив удалялась бы. Проще простого!

Но когда начнете решать проблему на нативном JS или на б-гомерзком jQuery, вы столкнетесь с необходимостью писать очень много шаблонного кода. Прежде всего на обслуживание DOM. Найти элемент, вставить элемент, добавить элементу класс, атрибут... в итоге у вас получится портянка на десятки строк для такой элементарной задачи, а ведь мы еще не добавили много кульных штук, без которых ToDoApp совсем не ToDoApp, как-то: возможность создавать разные списки, расписания, галочка, чтобы зачеркивать задачу и т.п. С реализацией всего этого ваша простыня будет расти, вы будете в ней путаться.

На этом этапе вы можете начать велосипедить. Писать какие-то утилиты для работы с DOM. Разделите index.js на несколько файлов, сообразно DDD или хотя бы единой ответственности. Допустим даже, что вашим приложением внезапно стали пользоваться, у вас куча бизнес-идей. Вы начинаете наваливать фичи, структура становится все запутаннее, кода становится все больше, а еще приложение начинает тормозить. Вы проводите небольшой анализ и понимаете, что проблема в излишне частом обращении к DOM - вы дергаете его на каждый чих, ведь с jquery это так просто! И что делать? Писать еще один велосипед, чтобы обновлять DOM пакетно? А как отслеживать изменения в данных с сервера? Это ж сколько работы!

К счастью, все вышеописанное, и даже гораздо больше, уже решено в Google, Facebook, а также некоторыми талантливыми энтузиастами. И у нас есть Angular, Vue, React, Svelte, которые предлагают вам возможность создавать быстрые, поддерживаемые приложения с минимумом шаблонного кода и продуманной архитектурой.

Не нужно так делать. Это бессмысленно. Ты импортируешь целый файл, чтобы достать из него ID, чтобы затем этот ID передать в другой компонент, чтобы затем он получил по этому ID этот же файл из спрайта, джизуз крайст... я не эксперт, но путь выглядит попорченным излишним рвением к овер-инжинирингу.

Вместо этого передавайте ID строкой. Спрайт вы и так сделаете при сборке отдельно, а вместо ID просто передаете название иконки вручную. Это ничем фактически не отличается от импорта вручную, зато гораздо проще и красивее.

1. Очень прост (кто бы что ни говорил, его концепция очень понятна и близка к стандартной концепции самого Реакта, Flux)
2. Саги (киллер-фича, мобх не может предложить такой мощи)

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

А вот в случаях, когда нужно положить в стор что-то локальное, например, при сабмите формы нужно переключить ее состояние; тогда пользуйтесь стейтом компонента. В случаях, когда один и тот же стейт требуют несколько компонентов (но не все приложение), можно извращаться по-разному. Мы в проекте на flux просто делали приватные сторы, которые шарились между соседними компонентами, и избегали расшаривания стейта между не соседствующими компонентами. Когда стор один, как в redux, можно использовать HOC, наследование или написать собственный хук.

1. Я бы попробовал обернуть в HOC withUser или сделать одноименный хук
2. Вообще это нормально. Обычный компонент, который рендерит то, что ему дают.
3. Сделать его умнее, чтобы получал эти данные сам. Тут перекликается с п.1

Видимо, у вас mobx? В console.log вы получаете доступ к самой переменной `processId`, в то время как в остальное время вам нужно только проверить, есть ли там свойство id. Напишите функцию следующим образом, и я уверен, что все будет работать.

@computed get inProcess() {
  return (id) => {
    const processIds = this.processId;
    return processIds.hasOwnProperty(id)
  }
}

А вот почему так - самому интересно)

window.onfocus и window.onblur, если я верно понял задачу. Первое событие выполнится, когда юзер перейдет на вкладку, второе - когда уйдет с нее

Я в своем проекте сделал надстройку над react-router, главным образом потому, что там коряво реализована интеграция с redux. У react-redux-router из коробки диспатч экшена происходит после того, как произошел собственно роутинг, т.е. налицо костыль; у меня же смена роута является следствием экшена, что мне и было необходимо достичь.

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

Например, код моего роутера:

Элементарно. При помощи вложенных циклов и \ или рекурсивно.

Очевидно, что она инициализируется с привязкой к конкретным элементам DOM. Решение проще пареной репы, производите реинициализацию при каждом рендере.

Модальные окна необязательно должны отдавать в render что-то, кроме как null, когда они "закрыты". Поэтому рендерьте окна ближе к корню DOM-дерева приложения, они будут рендериться, но в render будет null, если isShowModal = false.

Проверяйте Url и редиректьте. В чем проблема?

Самое время попросить эту библиотеку у Дедушки Мороза.

Если вкратце, то вы не сможете это сделать таким образом. Вам нужен HOC, который будет сдерживать демонтированный компонент на то время, что к нему применяется анимация. Смотрите в сторону CSSTransitionGroup, делал анимацию перехода с помощью этой библиотеки.

Я сделал просто: создал стили для print-режима, и при нажатии на кнопку вызвал window.print. А в стилях у меня в зависимости от активных компонентов некоторым присваивался display: none, а некоторые меняли свою раскладку и цвета. Никакие сторонние компоненты не потребовались в итоге.

// globals/index.js
const restApiHost = 1231313;
export { restApiHost };

// component.js
import { restApiHost } from './globals';
console.log(restApiHost);

Так?