Недавно меня спросили: “Зачем я отказался от библиотеки react-router и перешел на свой велосипед?” Честно говоря, вопросы, связанные с моим вариантом роутинга, мне задавали уже раз пять. Последний раз это было пол года назад, и с тех пор я немного подзабыл основные причины моего выбора. Поэтому я решил их вспомнить и написать статью о том почему react-router не подходит для больших проектов, поделится своими видением роутинга и получить критику моих идей от более широкого сообщества.

Где же держать бизнес логику приложения?

 "Та че уж там парится - прямо в компонентах." - скажут некоторые. И в некоторых ситуациях это правильное и удобное решение.

Но что если мы все-таки хотим чего-то большего? Например, масштабируемости, несколько юзер интерфейсов, лёгкой смены дизайна. Тогда логично разделить приложение на два слоя. Слой бизнес логики и слой представления. 

Как написано на сайте reactjs.org, React - это библиотека для создания UI. 

А для модели и бизнес логики написано несколько других замечательных библиотек.

Так уж получилось, что проекты, на которых я работал, использовали redux. Поэтому дальше речь про него. А конкретней - про то, как построить бизнес логику в большом react/redux приложении, чтобы потом не закрывать рукой глаза при виде того огромного количества редюсеров, экшенов и так далее и тому подобное.