Методологический вопрос, господа. Это редьюсер (один из). Ему нужны данные с

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

Скажите, а как среди бородатых и умудренных дядек принято разруливать сию проблему? Не пихать же весь редьюсер в промис!

Никак. Это не проблема, таков редакс. Приложение стартует на пустых стейтах и должно валидно отработать на первом рендере с пустым массивом. Когда придут данные, массив заполнится и приложение перерисуется.

А редьюсер в промис пихать нельзя. Редьюсер — чистая функция, он должен всегда возвращать значение

То есть, я должен в соответствующем компоненте поставить спиннер, запромисить фетч от бэка и, когда что-то приедет, обратиться к редьюсеру с экшеном на апдейт всего массива, типа так?

где-то повыше делаешь `if(props.users.length === 0) return <Skeleton />`и все - не будет попыток получить доступ к несуществующим данным

Не понял. Это как-то заблокирует функцию редьюсера?

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

Если коротко то редакс синхронен и чтобы все работало так как ты ожидаешь нужно использовать redux thunk или redux saga

ну, то есть, как я примерно и говорил - крутим спиннер в компоненте, пока не прилетит что-то вменяемое.

это миддловары какие-то?

Ну да, а как ещё с тз фронта это решить?

Именно

Да, читал как-то мельком, что есть такие и не совсем понимал, зачем, т.к. сам привык с редаксом работать напрямую. А воно оно че, Михалыч, это прокладки, которые тормозят редакс в нужные моменты, чтобы синхронизировать его с асинхронными запросами к бэку, верно я понимаю?

Да

Советую использовать thunk middleware

Они скорее тормозят екшны А редусеры отрабатывают на каждый екшн

Нет, в редьюсере хранить поле «загружаются ли сейчас данные и менять это поле в Пномпень начала и окончания загрузки. В компоненте слушать это поле и показывать спиннер. Ну и не запромисить фетч, а задиспатчить асинхронный (если redux-thunk) или обычный (если redux-saga) экшен, чтобы мидлваря начала фетчить

Они его не тормозят. Нельзя тормозить редакс

Но за счет чего-то они же согласовывают как-то редакс со всей остальной асинхронщиной?

тебе надо по дефолту переменную isFetching делать false потом после того как запрос прошел мкенять на тру

Выхватывают из потока редакса всю асинхронщину и крутят её сбоку. А в редакс диспатчат обычную синхронщину. Но потом

редакс санки возвращают по моему екшин который потом диспатчит редакс ,там все построено на замыкании

но прежде чем пулять синхронщину в редакс, нужно дождаться, пока асинхронщина сбоку докрутится.

Всё так. И в редьюсеры ничего не попадает, пока асинхронщина не докрутится. Просто сходи посмотри тутор какой-нибудь по мидлварям редакса, а потом по redux-thunk

Хорошо, благодарствую!

Достаточно понять, как работает мидлваря. В коде redux-thunk всего около десяти строк кода, они станут очевидны после вкуривания концепции мидлварей

около десяти строк кода вся библа???

да,можно при желании самому написать)

о, сколько нам открытий чудных готовит мир реакст стейт менеджеров )) погугли про https://github.com/storeon/storeon

В редаксе около 100 строк

Ivan 🧑‍🚀

Му-ха-ха!