Как разделить код работы с состоянием приложения?

Question

[Роман Якимчук]

Друзья,

По Redux есть одна мысль.

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

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

Должны быть инструменты, потому что это самая базовая фича при разработке крупных приложений, но в интернете шаром покати. Нашел https://github.com/ioof-holdings/redux-dynostore и https://github.com/Microsoft/redux-dynamic-modules, но как-то оно совсем не алё, поддержки никакой, документации никакой, и судя по исходнику, это не совсем то, что нужно.

Как вы эту задачу решаете?
Что-то используете, или сами пишете решение?

Comments

[Роман Якимчук]

Т.е. по идее должна быть структура, вроде:

src
  components
    foo
      index.tsx
      reducers.tsx
      actions.tsx
      ... другие файлы

... вместо популярной структуры:

src
  components
    foo.tsx
  reducers
    dataReducer.tsx
  actions
    dataActions.tsx

[camelCaseVlad]

Можете пояснить, при чем здесь структура дерева проекта?

[Роман Якимчук]

Допустим у нас 100 роутов в приложении и 200 компонентов. Если все экшены и редьюсеры держать в одном месте (папки actions, reducers), получится здоровенный список.

Так как при работе приложения большая часть редьюсеров и экшенов будет не подгружена (они будут загружаться по требованию), то смысла держать все эти файлы вместе нет:
а. Не будет понятно где какой редьюсер, или экшен. Их будет очень много, и не поймешь какой от какого роута или компонента.
б. Принято держать сущности в файловой структуре по какому-то принципу, и если в нашем случае принцип это формирование групп файлов связанных с одним компонентом, то эти файлы редьюсеров и экшенов нужно выносить именно к компонентам, если только они не глобальные.

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

camelCaseVlad

[Сергей Сунцев]

Роман Якимчук,

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

Да, все правильно, а в чем проблема? вы изначально инициализируете кучу редьюссеров, а потом, когда нужен компонент, использующий данные из стора, продолжаете.

Единственное, что если у вас их очень много, что это влияет на загрузку, то может у вас проблемы в архитектуре и стоит какие то одинаковые модели данных собрать в одну?

[Роман Якимчук]

Да, проблема может быть в производительности.

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

Единственное, нужно будет стор вычищать, но это не большая проблема.

Сергей Сунцев, что думаете?

[Сергей Сунцев]

Я понимаю, это удобно, но я бы не отказывался совсем от локальных состояний, надо просто понимать, когда состоянием нужно управлять извне, а когда не нужно.

Но надо в первую очередь ориентироваться на конкретный проект.

[Роман Якимчук]

Я тоже к этому пришел, да.