а, ты про мой изначальный вопрос?
Мы же в чате
Denis
Denis
Вопрос выше
Roman
@kelin2025
Ну вот представим себе что у нас на сервере в бд хранится больший список продуктов.
На сайте у нас несколько ProductGrid компонентов, в каждом из которых отображается часть этих данных..
например первый грид отображает первые 12 продуктов (sort by name)
второй отображает последние 8 продуктов (sort by price)
третий отображает первые 20 (filter by tag 'blabla')
Все эти данные довольно индивидуальные, по сути они не должны храниться в Store'е поскольку касаются только одного конкретного компонента и не делятся меж несколькими. Т.е. эти данные должны быть энкапсулированны внутри компонента.
теперь собственно вопрос: Как загрузить их асинхронно с сервака в asyncData и переместить в computed ?
Denis
Я не согласен
Roman
С чего ты решил, что им не надо в стор?
ну я-ж говорю: это не shared data, эти данные не делят меж собой несколько компонентов. Эти данные касаются только одного конкретного компонента.
Например если у нас несколько TextArea компонентов то расположение scroll-bar'а не должно храниться в Store'е ибо это касается только элемента TextArea
Завтра
Два варианта
- Если данных мало. Выгружаешь весь список в стор, в котором будут соответствующие геттеры. Логичное решение, но миллиард продуктов загружать - плохо
- Если данных много и нужно взять только какую-то выборку. Брать данные с сервера каждый раз. Но тут сталкиваемся с тем, что каждый раз одно и то же брать - тоже плохо. Посему можно кэшировать данные в localStorage, например, группируя по запросам, соответственно
Завтра
Короче говоря, если ты не можешь себе позволить выгрузить весь список в стор, то и нет смысла в него класть, вот
Denis
По uuid
Roman
cache это уже другая прослойка которая прячется за API интерфейсом через которые мы данные запрашиваем... если cache считаем нужным к серверу обратиться то он обращается, если нет - то нет.
а тут нам нужно лишь внутри компонента скачать с API интерфейса данные и переместить их в computed для локального отображения
Завтра
Если у тебя подразумевается, что будет пагинация (или infinite scroll) с дополнительной подгрузкой
То хранить в компоненте
Denis
cache это уже другая прослойка которая прячется за API интерфейсом через которые мы данные запрашиваем... если cache считаем нужным к серверу обратиться то он обращается, если нет - то нет.
а тут нам нужно лишь внутри компонента скачать с API интерфейса данные и переместить их в computed для локального отображения
Ром, ну я тебя умоляю... Эти кешей мильён
Roman
Если у тебя подразумевается, что будет пагинация (или infinite scroll) с дополнительной подгрузкой
То хранить в компоненте
ну так я об этом и говорю, что это энкапсулированные данные, их не нужно в Store пихать
Завтра
ин*
Denis
Складировать там
Завтра
Зачем?
Roman
именно, зачем?!
Завтра
Я написал альтернативу
Denis
Ваще нах стор?
Roman
грузит данные API интерфейс, если два компонента попросят его загрузить продукт X, то он естественно загрузит только один раз и расдаст 2 копии
Roman
ответственность за cache не в компоненте и не в сторе, а в API интерфейсе
Завтра
Группировать по запросам и кэшировать лучше, чем засирать стор разноперыми данными, которые никак не связаны между собой
Завтра
Короче говоря, храни в компоненте
Denis
Храните, где хотите
Roman
Короче говоря, храни в компоненте
ну это то я уже выяснил))) эт только Den почему-то не согласен
но вопрос то был КАК их там хранить
Denis
ответственность за cache не в компоненте и не в сторе, а в API интерфейсе
Ага, конечно. А this ты не кешируешь?
Завтра
@Romshark тут уже неоднократно писалось, что он вечно с чем-то не согласен и чаще всего чушь советует
Так что ¯\_(ツ)_/¯
Roman
Ваще нах стор?
для данных, которые делят меж собой несколько компонентов... если данные за пределы компонента не выходят - пихать их в стор нет смысла, ты лишь засоряешь стор и свои мозги лишним стейтом
Denis
Denis
Завтра
Flux паттерн используется для того, чтобы вынести общие данные наверх, а не чтобы запросы кэшировать
Roman
Запрос че один раз будет?
ты запрашиваешь данные с API прослойки, а он уже отвечает за устранение запросов на элементы которые в кэше есть, сам же компонент тупо постоянно просит API дать ему данные, ему неважно откуда они придут, с сервера или с кэша
Завтра
Flux паттерн упрощает использование одних данных в разных компонентах, а не разных в одном
Denis
ты запрашиваешь данные с API прослойки, а он уже отвечает за устранение запросов на элементы которые в кэше есть, сам же компонент тупо постоянно просит API дать ему данные, ему неважно откуда они придут, с сервера или с кэша
ПОТОМ БУДЕТ ЕЩЕ ЗАПРОС? ТАКОЙ ЖЕ СОСТАВНОЙ КАК И ПЕРВЫЙ?
Roman
если у тебя 2 компонента у API прослойки просят одни и те-же данные, то запрос на сервер будет лишь один...
Завтра
@Piterden ты что, тупой? Тебе объяснили уже 3 раза, что один запрос будет
Denis
Denis
Потом
Denis
Через 10 минут
Denis
я как раз таки тебе всё по полочкам раскладываю))
Ты мне раскладываешь про свой составной запрос. Я понял. Ты ответишь теперь на мой вопрос?
Denis
Потом
Denis
Будет
Denis
Запрос
Denis
???
Denis
Через 10 минут
Roman
если данные в кэше актуальны то нет
Roman
за кэш отвечает API адаптер, он самостоятельно распознаёт что ему запрашивать с сервера а что нет
Завтра
Завтра
Человеку объясняют, что есть отдельная прослойка, которая решает, делать повторный запрос или нет
Человек спрашивает, будет ли второй запрос
Denis
за кэш отвечает API адаптер, он самостоятельно распознаёт что ему запрашивать с сервера а что нет
А я тебе предлагаю не делать обращение к серверу если все данные уже в сторе
Denis
Roman
А я тебе предлагаю не делать обращение к серверу если все данные уже в сторе
этого И НЕ ПРОИЗОЙДЁТ 😄 тут стор совершенно не причём
Завтра
Дегроид
Завтра
Почему это так сложно для твоего восприятия?
Roman
Store != Cache
стор и кэш это принципиально разные вещи
Denis
Чем же?
Завтра
А я тебе предлагаю не делать обращение к серверу если все данные уже в сторе
Удачи хранить миллион товаров и каждый раз тянуть геттеры
Завтра
Чем же?
На этом можно закончить и сделать так https://habrahabr.ru/company/hexlet/blog/268249/
Stanislav
А я тебе предлагаю не делать обращение к серверу если все данные уже в сторе
А ему это и не надо. У него есть какая-то внешняя хрень, которая умная и сама решает, что делать, когда он попытается сделать запрос
Завтра
Да ограничение и все
Какое ограничение? По количеству данных?
Тогда ты не можешь утверждать, что в загруженной половине будут самые дорогие товары, ибо ты не знаешь второй половины
Denis
А ему это и не надо. У него есть какая-то внешняя хрень, которая умная и сама решает, что делать, когда он попытается сделать запрос
Че будет, если юзер будет вперед-назад щелкать роуты?
Roman
А ему это и не надо. У него есть какая-то внешняя хрень, которая умная и сама решает, что делать, когда он попытается сделать запрос
всё верно, за кэш отвечает другая прослойка и это архитектурно правильно поскольку не загружает башку разработчика излишним стейтом
Завтра
@Romshark короче, забей на него и храни в компоненте, ему бессмысленно объяснять)
Denis
А я знаю?
Я знаю. Сервак защитит кэш, про который Рома говорил. Но по сети полетят коллекции, которые уже 6 раз до этого загружались
Завтра
И, кстати, @Romshark, спасибо, подкинул мне еще одну идейку для apicase
Stanislav
всё верно, за кэш отвечает другая прослойка и это архитектурно правильно поскольку не загружает башку разработчика излишним стейтом
Да, здорово.
А оно где живет и как примерно реализовано?
Denis
Да граф же
Squall
думаю, что на картиночке все стили видно
так я тоже могу, меня интересовал способ с использованием гридов и стилей Vuetify, так как в одном месте нужно в другом нет. Но походу придется создавать какой-то врапер и ему стили писать самому.
Stanislav
Я знаю. Сервак защитит кэш, про который Рома говорил. Но по сети полетят коллекции, которые уже 6 раз до этого загружались
ты к тому, что компонент перерендерится и выполнится хук в котором данные запрашиваются?
Roman
Я знаю. Сервак защитит кэш, про который Рома говорил. Но по сети полетят коллекции, которые уже 6 раз до этого загружались
да не полетят 😃😃 API интерфейс не будет запрашивать данные у сервера по сетке которыми он уже обладает, это абстрагированно!!
если компонент дважды вызовет api.getProducts() то второй раз он просто получит данные из кэша, ничего по сетке не полетит