redux и api

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

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

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

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

Все лезут в API на каждый чих.иии

Ну а как ещё достичь консистентности данных?

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

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

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

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

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

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

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

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

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

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

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

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

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

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