Немного расскажу о концепции батчевых экшенов и батчевом редьюсере в Redux
В редьюсерах у нас много полей. Я не считал, не удивлюсь, если пара сотен.
TL;DR Сразу решение: gist.github.com/xnimorz/352a6c…
В коде привел объяснение подхода. Дальше в треде будет история: какую проблему решали, почему так сделали, какие профиты это нам принесло
Мы сделали систему, где при SPA переходе вызывается middleware, она делает GET запрос самостоятельно на нужный урл.
Прослойка на питоне собирает все данные от бекендов и отдает один большой JSON ответ.
У нас нет списка "вызови такие-то экшены при открытии такого-то урла", вместо этого, мы проходим по полям JSON и собираем набор "базовых" экшенов для того, чтобы на них вызвать dispatch.
Базовый экшен — у каждого редьюсера у нас есть экшен, который занимается тем, что передает данные as is в редьюсер (которые ему пришли). Выглядит так: gist.github.com/xnimorz/3cd1ce… и здесь базовый экшен передается третьим аргументом в createReducer.
Мы сейчас идем к тому, чтобы такие редьюсеры описывались еще проще: в конфиге стора была запись currency: typicalReducer();
Таких экшенов на большой JSON получается много. Они все записываются в массив actions и затем мы делаем dispatch(actions).
Мы диспатчим сразу массив экшенов, который на уровне рутового редьюсера итерируется и применяется вот так (ссылка с начала обсуждения) gist.github.com/xnimorz/352a6c…
Какие преимущества подхода:
Мы не завязаны на порядок применения. Либо все редьюсеры разово применились, либо нет. Нужно задиспатчить что-то, диспатчим разом
Автоматизировали процесс страничных переходов