LINUX.ORG.RU

redux и api

 , ,


1

1

Есть список товаров, который мы берем из API и кладём в Redux. Если мы кликаем на товар, то дальше переходим на описание товара и т.д..

Тут и возникла дилемма. Если список уже есть, то зачем делать сетевой запрос API и по Id брать описание товара (с DTO человек не заморачивался, объекты в Redux уже содержат всю инфо). Сказано - сделано. Всё работает, пока не перегрузим страницу. Чтобы этого избежать можно использовать redux-persist.

Правильный ли это поход? Или лучше дёргать API?

Что будет если товар изменился (цена, количество, наименование, описание и т.п.), а вы кленту показываете информацию, сохранённую неизвестно когда?

vvn_black ★★★★★ ()
Ответ на: комментарий от vvn_black

там довольно интересная концепция со слоями и так далее. ЭТо всё можно отслеживать (так называемый кеш).

Вопрос в том, что правильнее: гонять запросы по сети или (мы их всё равно получаем) настроить правильно хранилище?

FortyTwo ()
Ответ на: комментарий от vvn_black

Спасибо. Попробую вернуться к этому вопросу через время.

FortyTwo ()
Ответ на: комментарий от FortyTwo

настроить правильно хранилище?

Если есть время, то наверно так.
Никто не заморачивается, т.к. надо фичи пилить.

Shadow ★★★★★ ()
Ответ на: комментарий от Shadow

Агась. Именно, что никто не заморачивается. Но мы же получаем список объектов, чтобы показать. По уму мы его уже режем на пагинацию (блядское какое слово) выборку. Он у нас есть, если только мы не перегрузили страницу. Это чтобы не заморачиваться с локальным хранением у пользователя.

Что это даёт: по одной проверке мы узнаём, пуст ли список товаров. Если да - дёргаем API, но если нет, то перебираем по ID, ведь список небольшой, выборка.

Или все не заморачиваются и просто гоняют сеть?

FortyTwo ()
Ответ на: комментарий от FortyTwo

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

Вообще закидывать в редакс все подрят не круто. ОЗУ не бесконечная…. лучше подгружать все по мере необходимости

romanlinux ()
Последнее исправление: romanlinux (всего исправлений: 1)

Храни в IndexedDB (если немного данных, то в localStorage) то что не видно в списке, при просмотре доставай. Подписывайся по SSE (или websocket'ы) на обновления (можно в serviceworker'е), при отсутствии соединения оповещай что данные могут быть устаревшими. Если так мало кто делает - радуйся, будешь лучше большинства. Там ничего сложного - раз разобраться.

ddidwyll ★★★ ()
Последнее исправление: ddidwyll (всего исправлений: 2)
Ответ на: комментарий от romanlinux

Мне кажется грузить описание для всех товаров сразу это тоже не правильно.

Я тоже так считаю. Не зря придумали DTO.

FortyTwo ()

Я вообще юзаю Redux только там, где мне реально нужно глобально расшаривать данные. Ну, например, инфу о том, что юзер залогинен. То есть мне в зависимости от этого надо показывать/не показывать кнопку «Выход» в углу страницы, давать или не давать возможность писать комментарии по статьёй и т.п. - это всё разные компоненты, между которыми шарится состояние авторизации.

Но пихать в Redux всё подряд смысла нет. Тем более не эффективно для списка товаров хранить в Redux всю информацию по ним. Это не эффективно не только с точки зрения объема передаваемых данных по сети, но и с точки зрения реализации бэкенда, потому что при выполнении выборки из БД может с диска читаться гораздо больше данных, чем нужно. А если там в SQL SELECT *, то за такое по рукам бить надо.

Список товаров - это минимум информации о товаре, а детализация - это полная информация. Если и хранить это в Redux, то явно не в одном месте: есть список товаров, а есть детализация - не нужно их смешивать.

dimuska139 ★★ ()
Ограничение на отправку комментариев: только для зарегистрированных пользователей