При использовании Redux, как правило, лучше: внедрять специфичные для сущности редукторы или реализовывать универсальные редукторы , основанные на строгих соглашениях о ключах действий? Прежнее решение имеет много стандартного кода, но оно слабо связано и более гибко. В последнем растворе меньше образца, но он более хрупок и ограничен.
Поскольку в нашем домене десятки объектов, я изначально склонялся к последнему решению. Я разработал универсальный редуктор сущностей, который использует имена вычисляемых свойств JavaScript для манипулирования состоянием в соответствии с отправленными типами действий. Это все динамично и основано на соглашениях.
Сначала решение работало хорошо, пока я не понял, что в некоторых случаях использование структурного несоответствия между различными ресурсами сущностей. Некоторые конечные точки возвращают коллекцию, где некоторые возвращают отдельный результат и так далее. Таким образом, мне пришлось разложить общий редуктор, чтобы приспособиться к различным вариантам использования. Я начал добавлять фрагменты условной логики здесь и там. И в конце концов оказался потерянным и растерянным! Теперь мне трудно вернуть порядок в порядок. Архитектурно-ясное видение на самом деле оказалось очень сложным, чтобы быстро поддерживать большой шарик грязи.
Должен ли я просто отказаться от универсального решения и провести рефакторинг магазина, чтобы использовать редукторы, специфичные для сущностей, независимо от шаблона? Кто-то на самом деле успешно реализовал и поддерживал универсальную логику редуктора для сложного приложения с графическим интерфейсом администратора?