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

отдельный вопрос - размышление: есть запрос к апихе, ответ зависит от параметра (например автокомплит), и этот запрос вызывают несколько компонентов в разных частях приложения, с разными параметрами. Как лучше отдельно для каждого запроса рассчитывать состояние, тот же isFetching? Только созданием нескольких редьюсеров?

Для меня преимущество аксиоса в гибкости и какой-то предсказуемости интерфейса

А поконкретнее?

На мой взгляд axios это более лучший выбор чем fetch. Очень гибкий, простой в настройке под любые извращенные запросы. Для меня лично очень удобно оказалось возможность нескольких конфигураций для разных API, возможность интерсептить запросы итд

Объекту запроса делать в сторе точно нечего, как такая мысль в голову могла прийти

различные middleware пропускают через себя и url, и параметры, плюс у нас может появится cancelToken, я это имел в виду

Преимуществ очень много, на самом деле. Если простое приложение, с простым API на бэкенде достаточно fetch использовать и вобще не париться, но лично я всегда его использую(axios)

2 вопроса возникает в такой связке: 1) имеет ли смысл сохранять объект запроса и ответа в хранилище, или только data? 2) имеется в большом количестве шаблонный код обновления состояния на каждый запрос, обработка начала запроса, успеха и ошибки (стандартные isFetching, error, data) - что вы используете, для красоты и уменьшения кода?

Я, например, даже thunk не пользуюсь, предпочитая Redux-reducers, которые завязаны на "стандарт" Redux-actions. Ну и просто написал свой reducer, который обновляет состояние в store, передавая ему имя action

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

Я, например, даже thunk не пользуюсь, предпочитая Redux-reducers, которые завязаны на "стандарт" Redux-actions. Ну и просто написал свой reducer, который обновляет состояние в store, передавая ему имя action

Саги и танки же про сайд эффекты от экшенов, когда надо ещё один экшн начать

Я думаю, тут граница может быть размыта, на самом деле...

Саги и танки же про сайд эффекты от экшенов, когда надо ещё один экшн начать

А асинхронку как? =)

О, вот Женя может грамотно рассказать

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

окей, это информацию достаточно отправить в действие. А что насчет шаблонного кода?

Господа, есть такой вот mapStateToProps, где лучше всего вычислять countOfGuests и countOfCoupled? const mapStateToProps = (state) => { const { guestList } = state return { guests: guestList.guests, countOfGuests: guestList.guests.length, countOfCoupled: guestList.guests.filter((item) => item.coupled === true).length } }

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

О, вот Женя может грамотно рассказать

Я как раз пост написал только что

Про редакс

https://medium.com/@evgeny.rodionov/6a95feefcf29

Господа, есть такой вот mapStateToProps, где лучше всего вычислять countOfGuests и countOfCoupled? const mapStateToProps = (state) => { const { guestList } = state return { guests: guestList.guests, countOfGuests: guestList.guests.length, countOfCoupled: guestList.guests.filter((item) => item.coupled === true).length } }

В селекторах, можешь ещё reselect сюда прикрутить

хелперы хелперами, но обработка статусов различных запросов меня беспокоит, потому что выглядит вот-так:

Эээ

и огромная обработка каждого case

В редьюсере нужно хранить _ДАННЫЕ_

А не промежуточные состояния их

это пример к обработке запросов условного api/orders/:feature

Выглядит неправильно

В редьюсере нужно хранить _ДАННЫЕ_

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

https://medium.com/@evgeny.rodionov/6a95feefcf29

А что плохого тот же modalOpen в сторе хранить? Так я могу контролировать, что у меня не будет 2 модалки одновременно на экране

А что плохого тот же modalOpen в сторе хранить? Так я могу контролировать, что у меня не будет 2 модалки одновременно на экране

Я про single source of truth — когда в стор пихают вообще всё

Если ты знаешь зачем ты что-то делаешь, базару ноль

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

+

а как же http://redux.js.org/docs/advanced/AsyncActions.html#async-actions , стандартная обработка асинхронных действий

https://medium.com/@evgeny.rodionov/6a95feefcf29

Ну про connect вообще логично. Он же для этого и создан. Момент с чистым dispatch интересный. Момент с complexes и разбивкой на модули не сильно понятен. Кажется, что это лишь дело вкуса. UI state в store иногда сильно упрощает взаимодействие между разными компонентами React. Особенно в случае расположения в разных ветвях дерева, как раз избавляя от прокидывания свойств. Для меня правило такое: 1. Если ui-state влияет на другие компоненты, не являющиеся 1 уровня предком/потомком - то в store

Ну так изФетчинг это у тебя состояние приложения, но это не значит что у тебя на каждый запрос своё состояние должно быть)

Ну про connect вообще логично. Он же для этого и создан. Момент с чистым dispatch интересный. Момент с complexes и разбивкой на модули не сильно понятен. Кажется, что это лишь дело вкуса. UI state в store иногда сильно упрощает взаимодействие между разными компонентами React. Особенно в случае расположения в разных ветвях дерева, как раз избавляя от прокидывания свойств. Для меня правило такое: 1. Если ui-state влияет на другие компоненты, не являющиеся 1 уровня предком/потомком - то в store

Всё правильно

Вопрос, есть у вас компонент-функция и тут вы осознаете что нужно добавить state или что-то из lifecycle- будете переписывать на класс или враппер делать?

Ну так изФетчинг это у тебя состояние приложения, но это не значит что у тебя на каждый запрос своё состояние должно быть)

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

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

Вопрос, есть у вас компонент-функция и тут вы осознаете что нужно добавить state или что-то из lifecycle- будете переписывать на класс или враппер делать?

враппер , ты имеешь ввиду HOC?

враппер , ты имеешь ввиду HOC?

если будешь реиспользовать, то есть смысл делать декоратор, если нет. То перепсать класс, поидее так.

Вопрос, есть у вас компонент-функция и тут вы осознаете что нужно добавить state или что-то из lifecycle- будете переписывать на класс или враппер делать?

Разве переписать не быстрее, чем спросить? =) всего 3 строчки добавятся...

Без обид. На мой взгляд программирование - это хорошая вещь, чтобы быстро и эффективно эксперементировать. Это позволяет находить оптимальные конфигурации каждого конкретного случая. В особенности, если мы не говорим о фреймворках, а скорее о парадигмах (в плане React)

Ну так изФетчинг это у тебя состояние приложения, но это не значит что у тебя на каждый запрос своё состояние должно быть)

На каждый логический запрос (который может быть блоком из нескольких физических, например). В случае если приложение предполагает возможные параллельные независимые запросы

На каждый логический запрос (который может быть блоком из нескольких физических, например). В случае если приложение предполагает возможные параллельные независимые запросы

как раз кейс с параллельными запросами меня и интересует

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

Evgeny, this type of media is not allowed in this chat. (1/3)

Лол

Огонь

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

Результат отдельных запросов может влиять на вывод различных компонент. Соответственно, выводить из лучше сразу, а не блокировать пользователя до завершения всех. Это правильно с точки зрения UI (обычно)

Огонь

Неужели распознавание голоса все ещё плохо работает?

Моя речь полна терминов и англицизмов

как раз так я и делаю, в статье подробнее описано, ближе к концу блок про апи - https://habrahabr.ru/post/341132/

Фу хабр

на typescript кучу экшенов плодить не люблю, так как добавляется лишняя строка

Всем привет! Ай нид хелп. Делаем проект в связке Django Rest Framework - React,Redux,Router. Доступ к api осуществляется с помощью axios. Авторизация осущевляется с помощью токена. Столкнулись с проблемой неправильного кэширования данных, а именно, когда мы логинимся под пользователем и получаем данные по полученному токену все хорошо, но когда делаем logout, и заходим под другим пользователем приходят данные предыдущего пользователя, самое интересное, что каким то образом все кэшируется в браузере, какие только заголовки на отключения кэширования не пробовали, и система работает только при отключенном кэше в браузере. Может кто сталкивался?

Всем привет! Ай нид хелп. Делаем проект в связке Django Rest Framework - React,Redux,Router. Доступ к api осуществляется с помощью axios. Авторизация осущевляется с помощью токена. Столкнулись с проблемой неправильного кэширования данных, а именно, когда мы логинимся под пользователем и получаем данные по полученному токену все хорошо, но когда делаем logout, и заходим под другим пользователем приходят данные предыдущего пользователя, самое интересное, что каким то образом все кэшируется в браузере, какие только заголовки на отключения кэширования не пробовали, и система работает только при отключенном кэше в браузере. Может кто сталкивался?

redux-persist?

Это че за штука?

redux-persist?

Всем привет! Ай нид хелп. Делаем проект в связке Django Rest Framework - React,Redux,Router. Доступ к api осуществляется с помощью axios. Авторизация осущевляется с помощью токена. Столкнулись с проблемой неправильного кэширования данных, а именно, когда мы логинимся под пользователем и получаем данные по полученному токену все хорошо, но когда делаем logout, и заходим под другим пользователем приходят данные предыдущего пользователя, самое интересное, что каким то образом все кэшируется в браузере, какие только заголовки на отключения кэширования не пробовали, и система работает только при отключенном кэше в браузере. Может кто сталкивался?

заголовки + вкладка network в хроме в помощь

Всем привет! Ай нид хелп. Делаем проект в связке Django Rest Framework - React,Redux,Router. Доступ к api осуществляется с помощью axios. Авторизация осущевляется с помощью токена. Столкнулись с проблемой неправильного кэширования данных, а именно, когда мы логинимся под пользователем и получаем данные по полученному токену все хорошо, но когда делаем logout, и заходим под другим пользователем приходят данные предыдущего пользователя, самое интересное, что каким то образом все кэшируется в браузере, какие только заголовки на отключения кэширования не пробовали, и система работает только при отключенном кэше в браузере. Может кто сталкивался?

кэшируются куки?

кэшируется сам запрос

причем именно на стороне клиента

кэшируется сам запрос

ну откуда данные в него идут? Из формы?

можно сделать отдельную ветку в сторе с массивом pending, если массив пустой никаких операций не происходит, если в нём что-то есть, соотвественно, что-то происходит, если добавить какую-то мету можно будет создавать progress / loading ui элементы с фильтрами, естественно это уже не state данные. + как вариант можно написать свой класс, к нему мидлвэр в стор, и селектор через реселект, тогда редакс не юзается

кэшируется сам запрос

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

в идеале это должен быть локальный стейт, но доставить информацию в несколько лоадеров/прогресс баров как-то сложно без connect и redux

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

в том то и дело, что куки никак не учавствуют в доступе к апи

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

Браузер типо говорит, есть кэшированная версия запроса и отдает её

Браузер типо говорит, есть кэшированная версия запроса и отдает её

И даже запрос не прокидывает

Браузер типо говорит, есть кэшированная версия запроса и отдает её

хуйня какая-то

скинь заголовки запроса

и ответа

хуйня какая-то

ща

ребят, а можете подсказать, почему себя webpack dev server так ведет: если открываешь просто хост без пути, то отдает html c инклюдами с / в начале. а если открываешь хост с каким либо путем типа /foo/bar/, то / в инклюдах магически пропадает и путь получается относительным и соответственно нихрена не подгружается. historyApiFallback стоит, publicPath тоже. где я что промудил?

скинь заголовки запроса

Request Method:GET Status Code:200 OK (from disk cache) Remote Address:54.246.117.63:443 Referrer Policy:no-referrer-when-downgrade Response Headers Access-Control-Allow-Origin:* Allow:GET, PUT, HEAD, OPTIONS Cache-Control:max-age=600 Content-Language:ru Content-Length:243 Content-Type:application/json Date:Mon, 30 Oct 2017 08:50:12 GMT Expires:Mon, 30 Oct 2017 09:00:12 GMT Server:gunicorn/19.4.5 Vary:Accept, Accept-Language, Cookie Via:1.1 vegur X-Frame-Options:SAMEORIGIN Request Headers Provisional headers are shown Accept:application/json, text/plain, */* Origin:http://localhost:3000 Referer:http://localhost:3000/ User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36

вторая строчка

ответ берется из кэша

токен выпили

из сообщения

?

max-age=600

предлагаешь убрать?

да

no-cache пробовал?

пробовал, прописывал его в запросе в axios'е, корс вроде ругался

это сервер

сервер отправляет cache-control

И поэтому у тебя из кэша достается этот ответ

это сервер

А вот это уже интересно