методов апи по созданию, обновлению, проверке статуса и прочее, есть конкретная логика, в каком порядке какие методы вызываются, меняется в зависимости от разных параметров.
В общем редьюсере храню метаданные состояния на каждый запрос, и полученные на успешные ответы данные по заявке нормализую и обновляю в одном обьекте.
Запросы к бекенду - отдельный сервис, под капотом axios, специальных middleware не использую.
Обработка асинхронных действий - redux-thunk, в простых случаях все похоже на пример из документации redux.
Конкретные вопросы:
а) В асинхронные action creators имеет смысл передавать данные из других редьюсеров в качестве аргумента, или это нормально, получать все возможные данные из getState() внутри создателя действий? (Смущают action creators длинной в 20+ строк)
б) Стоил ли в этих action creators хранить логику (например нет id заявки, запускаем create, есть id, запускаем update, или когда начать пинг, а когда закончить), или и в компонентах можно решать такие вещи?
Может стоит добавить еще маленьких action creators, для выноса этой логики, а работу с api не перегружать?
redux-saga тебе поможет
a) Нормально (АС вроде и нужен для того чтобы логику туда пихать, куда лучше чем держать логику в редюсере) б) Это вопрос про диспатч экшна внутри АС вовсе иного экшна? Я думаю это вполне нормально, главное убедиться что вся логика которая там пишется, действительно касается только экшнов. Все же лучше чем в компоненте прописывать эту кашу, лучше завернуть логику в АС, и пусть компонент не париться что и когда вызывать
Обсуждают сегодня