обьект новый, вставь строку, не будет апдейтов новых

Тогда не работает поиск)))

Надо указать в scrollingWindow.current в массиве

есть реквесты к api через axios и три стула - обычный фетч - должна быть возможность для отдельных вызовов указать, что данные должны не фетчится, а браться из мока - NODE_ENV=test все данные берутся из моков есть какие-то рецепты как такое замутить?

есть реквесты к api через axios и три стула - обычный фетч - должна быть возможность для отдельных вызовов указать, что данные должны не фетчится, а браться из мока - NODE_ENV=test все данные берутся из моков есть какие-то рецепты как такое замутить?

А аксиос фетчем не надо заменять, затея скорее всего глупая и ничего хорошего из этого не выйдет

Чем аксиот от фетча отличается?

А аксиос фетчем не надо заменять, затея скорее всего глупая и ничего хорошего из этого не выйдет

я ни слова не написал про замену аксиоса на фетч

А какой сценарий, почему не просто все из моков?

> обычный фетч Это что значит?

тебе это слово знакомо исключительно как функция в js?

Звучит как оскорбление) "обычный фетч" в данном контексте может восприниматься только "как обычный фетч" и никак иначе, а что ты еще ожидал?

Чат по реакту. Холивар о фетче и аксиосе. На дворе мирно подходил к концу 2019 год...

один из бэкендов упал на деве, например. Или еще не готов

Чат по реакту. Холивар о фетче и аксиосе. На дворе мирно подходил к концу 2019 год...

Аксиос для редакса, фетч для всего другого

Самый простой вариант ловить ошибки и отдавать визависимости от ошибки результат. А вот ожидание готовности я всегда делал выше уровнем, не в апи

О, Тимофей)

Фетч также имеет необходимость внедрения десятков костылей в обертку, чтобы с ним было так же удобно работать как с аксиосом, при этом кстати интерцепторов нет

Фетч также имеет необходимость внедрения десятков костылей в обертку, чтобы с ним было так же удобно работать как с аксиосом, при этом кстати интерцепторов нет

У него достаточно четкий вопрос, а ты срач axios/fetch разгоняешь

Или мне может надо готовую реализацию прямо кодом скинуть?

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

Ребят, возвращаясь к теме useEffect, хочу спросить, это нормальная практика, что у меня useEffect посылает запрос к АПИ, как только компонент рендерится на странице? (в моем случае это поле для поиска). Или правильнее будет сделать вызов useEffect по кнопке поиска?

По кнопке или debounce ввода

Мне вот интересно, между хуками и обычными компонентами, в чем наиболее разница проявляется?

здарова) если не занят запускаю axios-запрос в самом компоненте (позже перекину его в экшены) и console.log(products) показывает как стейт заполняется продуктами, но axios-запрос постоянно запускается я пытался засунуть запрос в useEffect и продукты в deps, тоже самое

все логично

здарова) если не занят запускаю axios-запрос в самом компоненте (позже перекину его в экшены) и console.log(products) показывает как стейт заполняется продуктами, но axios-запрос постоянно запускается я пытался засунуть запрос в useEffect и продукты в deps, тоже самое

есть реквесты к api через axios и три стула - обычный фетч - должна быть возможность для отдельных вызовов указать, что данные должны не фетчится, а браться из мока - NODE_ENV=test все данные берутся из моков есть какие-то рецепты как такое замутить?

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

когда делаешь запрос deps надо оставлять пустым массивом, а ответ закидывать в стейт, к примеру

ок а если я хочу чтобы запрос ничего не возвращал, а заполнял состояние в редаксе, и я выкачивал ответ из хука? const products = useSelector(state => state.products.allProducts.products);

Обёртка над обёрткой и немного сервис воркеров

А для чего кстати сервис воркер?

Взять эффектор

useEffect?

Так можно просто перед запросом если условия для мока выполняются, возвращать мок, не?

Не. Это внедрение в код

ок я не хочу лишнюю библиотеку. тогда пусть запрос и заполняет стейт и возвращает продукты

ок я не хочу лишнюю библиотеку. тогда пусть запрос и заполняет стейт и возвращает продукты

ок я не хочу лишнюю библиотеку. тогда пусть запрос и заполняет стейт и возвращает продукты

Это не лишняя))) это полноценное управление логикой. То что ты сейчас делаешь это антипаттерн — смешивание логики и представления. Эффектор позволяет отделить логику и решать твои вопросы на раз два

ок а если я хочу чтобы запрос ничего не возвращал, а заполнял состояние в редаксе, и я выкачивал ответ из хука? const products = useSelector(state => state.products.allProducts.products);

вот только сам реакт упрямо затягивает логику во view слой

вот только сам реакт упрямо затягивает логику во view слой

В компонентах представления может быть логика именно самих компонентов. Бизнес-логики там быть не должно

ок а вынести сетевую логику в Action файл таким образом тоже не верно?

redux-thunk

ок а вынести сетевую логику в Action файл таким образом тоже не верно?

В общем я тебе написал что делать. Выкинуть всю логику из компонентов. Взять санки или саги. Если боишься эффектора

В общем я тебе написал что делать. Выкинуть всю логику из компонентов. Взять санки или саги. Если боишься эффектора

На правах "поддакивания" - санки, саги или RxJS в частности redux-observable (попытка не пытка, но если зайдёт много где ещё может пригодиться)