это тогда не сервис) а набор функций

При росте проекта будут проблемы в навигации и внедрении новичков в эту схему работы, для себя в пока выбрал container/actions|reducer|..

А кто нить использует слово model для этого? (и внутри него уже храня редьюсеры/экшены и т.д.)

т.е. по вашему сервис без хранения состояния это не сервис?

Это совсем не туда уже

А почему?)

Модель в общем понимании - это класс описывающий какую то структуру данных и методы работы с ней

то о чем вы говорите - это хэлперы стейт-менеджера  и сайд-эффкты для них

Разделите ваше приложение условно на framework-specific и framework-agnostic функционал. То что относится к framework-agnostic скорее всего и является вашей бизнес-логикой. Вынесите его куда то в отдельный сервис и переиспользуйте в стейт-менеджере обычными вызовами методов

Или рассмотрите на примере "калькулятора". Слой UI понятен, слой бизнес-логики в этом случае может выполнять класс Calculator который описан в модели. ВЫ можете для реализации калькулятора взять стейт-менеджер и нафигачить редьюсеров. Но так или иначе каждый редьюсер - это функция реализующая часть бизнес-логики которая может быть вынесена - допустим в сервис "calculator.service.js". И этот "набора функций" как сказали выше - вполне себе бизнес-логика которую можно достаточно легко переиспользовать в случае отказа от стейт-менеджера. Это мое ИМХО

Если мы о таком формате говорим - тогда по моему мнению это было бы так
ui - компоненты интерфейса
state - хранилище состояния (как раз весь список того что у Вас описано)
services - набор тех самых "чистых" функций для бизнес логики и доступа к данным
repository - слой доступа к данным (http, ws, graphQL, etc.)

Итого схема была бы приблизительно такая
UI -> State -> Service -> Repository

спасиб, шо расписал

ну это работает только для калькуляторов или чего то очень простого

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

я понимаю корни разделения на services / repository, так на бэке делают например, но даже там они вообще не framework агностик

Зависимости между сервисами - реализуются через dependency injection.
Если у Вас стейт обращается напрямую к репозиторию - значит что рефакторинг будет мягко говоря не простым. С такой логиком можно все фигачить прямо в компонентах - почему бы и нет?

Как то люди раньше жили без редуксов и ничего :)

Ребят помогите, такая проблема, обновил node.js , у меня вебпак gulp ,запускаю страницу по команде gulp и такая ошибка в терминале, с чем связано? после обнове node такой прикол

Проблема скорее не с галпом, а с node-sass
У меня была когда-то ошибка, что node sass v5 ругался то ли на новую ноду, то ли на реакт 17-й версии
Попробуйте удалить текущий node sass и установить "npm i node-sass@4.14.1", мне в свое время это помогло