Comments 28
Допустим, приложение A должно реагировать на событие приложения B, для этого A подписывается на action’ы приложения B и реализует собственную логику.
Вам не кажется, что эти приложения получаются слишком сильно связанны? Коммуникацию между компонентами вы тоже так реализуете, что один компонент стучится к состоянию другого компонента? Если нет, то чем приложения хуже?
Приложения могут разрабатываться разными командами, у них есть некоторые контракты, по которым они работают. Допустим, одно из приложений реализует broadcast-сообщения внутри себя, например, сервис уведомлений, тогда соседнее приложение может подписаться на этот канал и реагировать соответствующе при наличии срочных сообщений, на которые оно настроено. Внутри приложений компоненты используют общий store, поэтому это проблем с коммуникацией не вызывает.
Так а что мешает и приложениям использовать общий стор? У нас вот приложение — такой же компонент, как и все остальные. Можно запросто вставить одно приложение в другое. Или сделать третее, которое объединяет два независимых приложения в одном. Например, у нас есть приложение "webdav клиент" и есть "телефонная книга", а есть приложение "всё, что нужно работнику", которое в качестве отдельных разделов содержит списки файлов из разных директорий и телефонный справочник предприятия.
Если над приложением работает одна команда, то да, это реализуется без проблем, но когда над разными кусками работают разные команды, могут возникать коллизии имен action'ов, отсюда вырастает потребность в синхронизации. С реализией в несколько store'ов такая проблема отпадает.
Нет, тут вырастает потребность в инкапсуляции. Эта проблема показывает ущербность глобального хранения состояния. Мы проходили уже через это многие десятилетия назад, но продолжаем регулярно ходить по одним и тем же граблям. Стор — те же глобальные переменные со всеми вытекающими. Экшены — те же процедуры со всеми вытекающими.
Скажите, а как вы без React Router прикручивали state к истории браузера (если прикручивали)? И писали ли для этого свой компонент или нашли готовое решение? Спасибо!
… срабатывает соответствующий reducer, возвращающий новый state
Срабатывают ВСЕ редьюсеры и вся middleware.
Срабатывают ВСЕ редьюсеры и вся middleware.
Срабатывают ВСЕ редьюсеры и ВЕСЬ middleware.
Если бы, как указали ниже, подразумевалась «цепочка», то было бы правильно
"все" это отличный аргумент.
Но Хьюстон, у вас проблемы.
Средний уровень интеллекта этих "всех" по правилам нормального распределения не слишком высок
По правилам нормального распределения он средний.
В точку. Именно из-за этого низкого уровня середины и начали склонять пальто (пальта, пальте), писать вкуснОЕ кофе...
Середина не может быть низкого уровня, поэтому она называется серединой.
Какую из них вы упомянули? Среднее арифметическое? Медиану? Мат.ожидание?
И, да, это разные величины.
И, да, второй раз, низкое/высокое имеет значение относительно точки отсчета.
Если уж упомянут низкий средний уровень интеллекта, то вполне естественно что точкой отсчета является нечто находящееся выше этого самого уровня.
Ваш учитель и К.О по совместительству…
Нужно все как следует нормализовать и отделить данные (кэши сущностей) от состояния сессии (все, что связано с текущим пользователем) и от ui (все, что относится непосредственно к рендерингу — текущие открытые попапы, выезжающие меню, роутинг и т.п.).
Самая большая ошибка при старте — пытаться уложить все в редьюсерах для кусков интерфейса из серии «тут у нас редьюсер меню, тут хэдер, тут страница пользовательских настроек). Тогда как в редьюсерах по большей части должна лежать модель приложения, абсолютно отвязанная от интерфейса.
Redux подразумевает работу приложения вообще без какого-либо UI, ну т.е. это просто модель, управляемая экшенами. То, что эта модель имеет отображение в UI — только надстройка. Соответственно, опираться в модели на куски этого отображения неверно. Максимум, что можно сделать — выделить отдельный ui-редьюсер с минимальным необходимым набором значений, без которых, что самое главное, приложение продолжит работать.
Update: более того, с ростом приложения вы начнете искать средство избавления от головной боли толстых экшенов и сайд-эффектов. Ближайшие кандидаты — redux-saga и redux-observable. Оба описывают процессы в модели, и оперировать в них вещами из UI-представления — по меньшей мере странно.
В программе выступления по актуальным темам разработки, мастер-классы и демонстрация передовых разработок на основе технологий искусственного интеллекта, биометрии, дополненной и виртуальной реальности.
Вход свободный по предварительной регистрации https://ufs-programm.timepad.ru/event/490838/
Актуальная программа и новости мероприятия в группе https://www.facebook.com/groups/433394900345631/
Redux как сердце архитектуры фронтенда Единой фронтальной системы