Расскажите вашу историю успеха или фейла с redux или аналогичной библиотекой. Какие проблемы хорошо решились? Какие проблемы не решились? В итоге — хорошо или плохо? Станете ли использовать в следующем проекте?

Из моего опыта на Angular с ngrx и ngxs:

1. Разделение на action/reducer сильно заморачивает навигацию по коду. Видишь код типа store.dispatch(createOrder()) — нельзя просто тыкнуть мышкой и попасть в однозначный обработчик "create order", нужно искать конкретно reducer (многие reducers) где используется createOrder. Да, это здорово, что actions можно например логировать, но это очень побочная плюшка.

2. Хранить всё состояние в одном большом объекте — странная идея. Во-первых это в любом случае не всё состояние, а только кусок состояния фронтэнда, а во-вторых может мне удобнее часть локальных данных хранить в какой-нибудь маленькой броузерной nosql базе? Да, это здорово, что состояние можно логировать, но это снова побочная фича.

3. Reducers — странная идея. Очень бодро звучит: "это единственное место, где изменяется состояние" и "их очень легко тестировать, потому что стейтлес", но дальше не понятно. Почему я должен хотеть единственное место, где изменяется состояние? Я, может, мог бы это как-то принять, если бы оно не уродовало код, но ведь уродует. А "легко тестировать" — вообще не понятно. Внедрили синтетическую сущность, которая толком не делает ничего осмысленного, а выполняет какой-то огрызок работы — и её легко тестировать.

4. Сама идея иметь глобальный объект store на который завязано вообще всё — полная хрень. Смотришь ты на компонент CreateOrderPage — от чего он зависит? От store! Отлично. Смотришь на компонент LogInPage — от чего он зависит? От store! Т.е. код становится менее описательным и более синтетическим. LogInPage очевидно не должен быть никак связан с функциональностью создания ордеров — и здорово бы это видеть в явном виде, но нет — store и всё тут.

С другой стороны без этих библиотек тоже не очень понятно как сделать нормально. В некоторых случаях решения "прямо из кода компонента сделаем запрос" хватает, в некоторых возникает желание вынести этот код в отдельный сервис, особенно если есть логика, которую хочется тестировать. В итоге получается как-то ad hoc без внятных ответов. Хочется какой-то более системный подход.

R>Расскажите вашу историю успеха или фейла с redux или аналогичной библиотекой. Какие проблемы хорошо решились? Какие проблемы не решились? В итоге — хорошо или плохо? Станете ли использовать в следующем проекте?

ну так себе, честно говоря. использовал там, где состояние и так лежит в здоровенном дереве — просто потому, что его на сервак гонять надо.
если опять попадется похожая ситуация — буду использовать, иначе — не кажется мне, что оно того стоит.
бесит многословность. начинаешь с ней бороться — получаешь какой-то хитровывернутый код, который сам потом с трудом понимаешь. в общем, просветления я не достиг

Здравствуйте, rosencrantz, Вы писали:

R>3. Reducers — странная идея. Очень бодро звучит: "это единственное место, где изменяется состояние" и "их очень легко тестировать, потому что стейтлес", но дальше не понятно. Почему я должен хотеть единственное место, где изменяется состояние? Я, может, мог бы это как-то принять, если бы оно не уродовало код, но ведь уродует. А "легко тестировать" — вообще не понятно. Внедрили синтетическую сущность, которая толком не делает ничего осмысленного, а выполняет какой-то огрызок работы — и её легко тестировать.

R>4. Сама идея иметь глобальный объект store на который завязано вообще всё — полная хрень. Смотришь ты на компонент CreateOrderPage — от чего он зависит? От store! Отлично. Смотришь на компонент LogInPage — от чего он зависит? От store! Т.е. код становится менее описательным и более синтетическим. LogInPage очевидно не должен быть никак связан с функциональностью создания ордеров — и здорово бы это видеть в явном виде, но нет — store и всё тут.


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

Здравствуйте, rosencrantz, Вы писали:

R>С другой стороны без этих библиотек тоже не очень понятно как сделать нормально. В некоторых случаях решения "прямо из кода компонента сделаем запрос" хватает, в некоторых возникает желание вынести этот код в отдельный сервис, особенно если есть логика, которую хочется тестировать. В итоге получается как-то ad hoc без внятных ответов. Хочется какой-то более системный подход.

по причинам аналогичным описанным, выбросил redux
пересел на mobx
хотя то что там происходит в последних версиях тоже не особо устраивает

Здравствуйте, rosencrantz, Вы писали:

R>С другой стороны без этих библиотек тоже не очень понятно как сделать нормально.

У него могут быть плюсы в определённых случаях. Например

— Undo/Redo (запоминание и восстановление состояния). Во всяких редакторах это есть очень полезная фича
— Синхронизация состояния с сервером, или другими клиентами (совместное редактирование например)

Для просто обычного приложения оно как-то не особо понятно зачем.