Опыт использования redux без редьюсеров

Позвольте только вопрос. Насколько понимаю, action-type у вас является константа вида «A.B.C» (либо массив/объект). Вы его импортируете из того же файла где лежит и хэндлер. А потом, диспатчем бросаете тип в «черный ящик», который, по факту, тут же вызывает ваш хендлер по принципу reducer['A']['B']['C'](state, action). В чем сакральный смысл такого непрямого вызова? Активно пользуетесь мидлварами? Или просто удобно часть «модульной» логики класть в редьюсеры вне хэндлеров?

Честно говоря, я вас не понял. Но попробую ответить:

1. action-type-ом у меня являются строки, в которых есть префиксы
2. action-type-ы никуда не импортируются (а зачем?)
3. вместо них импортируются actionCreator-ы для mapDispatchToProps
4. "reducer"-ы не вызываются по принципу reducer[prefix1][prefix2][prefix3]. reducer-ы не являются какими-то очень универсальными, работающими по какому-то конкретному механизму. Они могут быть произвольными. Ну вот так например:

import { map as mod1 } from 'mod1/redux';

// reducer in the middle
export default (state, action, rootState) =>
{
  if(action.type.startsWith('mod1'))
  // or if(action.type in mod1)
  {
    const handler = mod1[action.type];
    const field1 = handler(state.field1, action, rootState);
    return { ...state, field1 };
  }

  if(action.type in ownMap)
    return ownMap[action.type](state, action, rootState);

  throw new Error(`unsupported action-type: ${action.type}`);
}

По сути ― тут идёт проверка на action-type и перенаправление его вложенному reducer-у. Предполагается, что вложенный reducer работает с каким-то конкретным полем. Вызываем его с нужным ему куском state-а и по результату меняем его же поле в state.

Пример типовой, по факту же всё может быть совсем по-другому, т.к. real life задачи бывают сильно сложнее и причудливее. Но логика та же — в вышестоящем reducer-е мы можем произвольным образом вызывать нижестоящие. Если там удобно написать что-то хитрое — пишем. Если там всё просто — стараемся сделать всё предельно декларативно, почти без кода.

диспатчем бросаете тип в «черный ящик»

Понравилась формулировка. Я так понимаю, этим вы хотели сказать, что нижестоящий reducer не знает как с ним будет работать вышестоящий reducer и будет ли вообще. Да? Ну дак это прекрасно, имхо. IoC в действии.

Активно пользуетесь мидлварами?

Только thunk, не более. Схема простая как валенок, middlewares не требуются.

Или просто удобно часть «модульной» логики класть в редьюсеры вне хэндлеров?

Тут пожалуй я окончательно запутался. Что есть "модульная логика" и что есть "хэндлер"? В reducer-ах у меня есть "кастомная" логика по распределению ответственности — какой конкретно подредсьсер будет ответственным за какие типы action-ов, и какие куски state-а его должны интересовать, и как их обрабатывать. То как это сделать в конкретном месте — решается согласно задаче. По сути так, как это будет удобнее. Чем меньше нижестоящий reducer знает лишнего, тем лучше, не его ума дело. Поэтому сигнатуры от задачи к задаче могут меняться. Ладно, что-то меня понесло в дебри.

Ячейки привязаны стандартным connect через mstp вида

Ну вот тут мы и приехали. Сразу. Судите сами: у вас на экране 20 колонок и 30 строк. Это 600 ячеек. Сразу 600 subscribe-ов к connect-у. Которые будут отрабатываться вообще на любой чих. Какую часть store вы бы не изменили, вызываются ВСЕ АБСОЛЮТНО подписчики. Берём экран побольше — теперь у нас не 20х30, а скажем 25х40 = 1000. Беда. Усложняем ячейки (они же по своей природе могут быть сложносоставными). Получаем 2000, 3000, 4000… И т.д… Так проект не взлетит.

В чём проблема? В том что у вас вызываются тысячи mapStateToProps. Они что-то делают (обычно они легковесные). Их результат подвергается shallow-comparison проверке. Чем больше полей, тем дольше. Практически всегда проверка выдаёт, что данные те же, и дальнейший render не требуется. Приемлемо ли это? Нет, конечно. Есть ли нормальные пути решения? Да, конечно.

Как решать? Ну первое что приходит в голову, это иерархический connect. Скажем если поменялось что-то вне таблицы, то зачем вызывать эти наши тысячи mapStateToProps? Стало быть subscribe на таблицу должен быть 1, а в нём уже кастомная логика дилегирования нижестоящим звеньям. Ну дальше надо уже плотно думать опираясь на задачу. По сути говоря задача написать такой "connect" который опираясь на кастомную логику задачи будет дёргать как можно меньше лишних участков кода. Из коробки redux даёт доступ к глобальной области всем connect-ам. Ввиду этого вынужден вызывать вообще все subscribers.

Судя по имеющемуся опыту, каких либо проблем быстродействия тут быть не может. Даже если добавить вычисление эпических формул между ячейками.

Я надеюсь это была шутка )

Если кратко охарактеризовать сущность вашей схемы в отличии от базовой:

В самой в базовой схеме все actionCreator-ы обязаны создавать plain object action с полем type. В расширенной для асинхронности добавлены redux-thunk или redux-saga или ещё чего. В вашем случае видимо redux-thunk. Вы используете его для получения getState. В базовой схеме reducer выполняется над данными после dispatch-а action-а в store. У вас же наоборот, reducer выполняется в обход redux-а, когда душе угодно, а в redux уже уходят готовые данные для замены. В базовом виде reducer-ы дробятся иерархично, и каждому подредьюсеру доступен свой кусок state-а. У вас всё работаете через getState и линзы-селекторы, т.е. "глобально". Ну и в целом если подвести — в базовом виде action-ы, actionType-ы, actionCreator-ы, reducer-ы — всё отдельные сущности, с друг другом связанные лишь косвенно (к примеру action.type-ом). В этом философия ынтерпрайза на redux. У вас это одна большая сущность, которую при желании можно декомпозировать, но можно и не декомпозировать.

Подходов когда выбрасывается большая часть redux цепи уже много. Ваш от большинства тех, что я видел отличается тем, что getState вызывается до dispatch-а plain action-а. Т.е. у вас "внешний" reducer. А потом все action-ы thunk-уты. Обычно делали не так, то что у вас называется setState и является скорее newState: data, обычно это делают методом, который вызывается всё таки из reducer-а, а не за его пределами. Хотя результат тот же.

Все эти подходы напоминают Vuex. Там посмотрели на redux, посмотрели на vue, взяли redux и написали с нуля, но выкинули практически всю ынтерпрайзную бюрократию, добавили какой-то своей мути (модули), добавили к этой мути костылей, получили довольно компактное решение. В живую ещё не пробовал, но после пары лет redux-а — подход Vuex выглядит гораздо аппетитнее. Особенно ввиду отсутствия необходимости морочить себе голову с immutable-значениями, там вместо этого observable-реактивность. Планирую следующий небольшой проект сделать на vue+vuex чтобы распробовать.