Есть два хороших подхода к организации кодовой базы, которые подходят для большинства проектов: File Type First и Feature First:
Пример Feature First
Проект:
/common
/api
/components
/ducks
/entities
/sagas
/selectors
/utils
/features
/Feature1
/Feature2
/Feature3
/Feature4
...
/FeatureN
/Main
/pages
index.js
App.js
routes.js
rootReducer.js
rootSaga.js
store.js
/Auth
/pages
index.js
App.js
routes.js
rootReducer.js
rootSaga.js
store.js
...
Отдельно взятая Feature:
/features
/Accounts
/components
index.js
accountsDucks.js
accountsSaga.js
accountsSelectors.js
accountsApi.js
Accounts.js
AccountsContainer.js
Пример File Type First/actions
/common
/components
/core
/Feed
/Profile
...
/constraints
/containers
/entries
/locales
/pages
/reducers
/utils
...
Оба подхода при умелом использовании они отлично масштабируются, поддерживаются и не вызывают проблем при рефакторинге.
Дата мапперы в зависимости от задач можно использовать в редьюсерах, в mapStateToProps и asyncActions. Главное чтобы по проекту все было стандартизировано.
В mapStateToProps пишут преобразования необходимые лишь для одного компонента.
Большое количество бойлерплейта это плата которую вы платите за использование redux. Можно писать все константы и редьюсеры руками, можно использовать библиотеки вроде redux-actions и ей подобные. В первом случае вы получаете плюс к гибкости, читаемости и статическому анализу, во втором меньше кода. Я в большинстве проектов предпочитаю первый вариант. Так же создаю шаблоны файлов в Webstorm для asyncActions, contstraints, редьюсера, страницы, компонента и законнекченого компонента.
В специфичных проектах с множеством CRUD запросов и похожих сущностей есть смысл написать CRUD Boilerpalte.
