Почему рекомендуют использовать Vuex как прослойку для работы с API (через axios)?
Во всех уроках по Vue делают запросы к API внутри actions Vuex store, коммитят данные в state и их уже берут в компоненте.
Никак не могу понять, в чём смысл такой прослойки и почему никто не обращается к API минуя Vuex.
При использовании данного рекоендуемого во всех уроках подхода, никто не объясняет, что делать с этими данными, когда я произвожу добавление/обновление новых данных.
Допустим, у меня есть блог. В блоге есть: список статей (с пагинацией), "последние добавленные", "самые популярные" и что-нибудь ещё. А ещё есть страница публикации.
Получается, мне нужно плодить стейты, геттеры, сеттеры и мутации для каждого вида списка, для страницы публикации тоже.
А что делать с этими данными во всех стейтах, когда я отредактировал какую-то публикацию?
А что делать, когда я вообще ухожу с блога на другой раздел сайта? Чистить стейты или оставить висеть в памяти?
Вопросы выше - скорее риторические. А фактический - далее.
Действительно ли есть какой-то смысл в использовании Vuex как прослойки для работы с внешним API (как на чтение, так и запись) или его использование таким образом гайдах/уроках/туториалах избыточно, и стоит использовать по более общему назначению, например хранению состояния авторизации?
К слову, нигде в официальной документации я не нашёл рекомендаций использовать его как API-прослойку, а вот в уроках - только такой подход и используется (как русские, так английские).
Можешь не использовать, перенос бизнеслогики на фронт не к чему. Я храню в сторе, только ту информацию, которая действительно нужна во всем приложении, информация о пользователе, настройки, а всё остальное в самих компонентах запрашивается по необходимости. К тому же это способ поддерживать актуальную информацию из бд.
Во всех уроках по Vue делают запросы к API внутри actions Vuex store, коммитят данные в state и их уже берут в компоненте
чтобы показать, как он работает
Никак не могу понять, в чём смысл такой прослойки и почему никто не обращается к API минуя Vuex.
если данные не нужны в других компонентах, то vuex не нужен. правда, архитектура может измениться, и данные могут быть востребованы глобально. Но это уже вопрос верной архитектуры приложения
Vuex используется как хранилище. Компоненты как его потребители.
Это позволяет разделить приложение на слои и не смешивать логику и отображение и упрощает тестирование.
И типичный пример.
У вас есть 3 компонента на 1 уровне посты, паджинатор и фильтр
причем паджинатор и фильтр дублируются. То есть вместо простого отображения вам нужна и логика и оповещения контрола высшего уровня. Кошмар!
Если бы пример был применим к моему случаю, я бы что-нибудь понял, но у меня на фронтэнде нет никакой логики, она вся на бекенде, я просто передаю в API запрос номер страницы и параметры фильтров, а бекенд мне возвращает всё готовенькое: и офильтрованные данные, и пагинацию, и я просто вывожу только то что пришло с сервера и ничего не делаю. Зачем здесь хранилище?
простые приложения могут легко обходиться и без Vuex. Возможно, будет достаточно простого паттерна глобальной шины событий. Но если вы создаёте SPA среднего или крупного размера, то, скорее всего, уже сталкивались с ситуациями, которые заставляли задуматься о том, как лучше управлять состоянием вне компонентов Vue, а Vuex в таком случае может стать вполне естественным следующим шагом.
WapSter, я ответил на его комментарий с описанием того что у него сейчас есть. Понятное дело ему не нужен сейчас VUEX, а если потом от данных полученных сервера может что то зависеть в других компонентах? Разве не удобнее в таком случае делать запрос через VUEX, и потом уже в каждом компоненте получать нужное, вместо того что бы каждый раз из каждого компонента отправлять запрос на сервер.
И тогда вопрос
бекенд мне возвращает всё готовенькое: и офильтрованные данные
Не будет ли в таком случае если понадобится отфильтровать по другому нагрузки на сервере? Если только из за одной фильтрации делать запрос что бы данные на сервере по нужному отфильтровать, не легче это делать с уже полученными данными?
Скажу сразу я возможно не очень хорошо разбираюсь, так что критику приветствую) или можешь поправить если не прав)
Alex_mos, в базе 10 тысяч записей (или 100 тыс, или 1 млн), мне нужно отфильтровать (найти) по какому-нибудь параметру и получить, допустим, первые 100 результатов.
Не вижу смыла делать фильтрацию на фронтэнде, ведь тогда мне нужно будет поместить в стор весь массив данных, чтобы их фильтровать.
Я же просто передаю в api параметр для фильтрации и бекенд отдаёт мне результат, то есть в итоге вся фильтрация происходит в SQL-запросе.
Alexander Lashchevsky, так получаете в компоненте эти данные, а если от этих данных зависит состояние в другом компоненте. К примеру, при получении этих данных, в хедере вывести что то...(к примеру количество полученных данных)
Думаю будет удобнее получить данные в vuex и уже эти данные использовать в компонентах..
Наверное тупой пример...
В общем, суть в том что бы компоненты приложения могли иметь доступ к одним и тем же данным, видимо по этому и рекомендуют как прослойку для API
Владимир Коротенко, как вы решите такую задачу: есть список статей с пагинациейи на этой же странице можно в попапе отредактировать статью и привязать к ней связанные статьи, выбрав их из списка статей
Владимир Коротенко, вы не поняли вопрос. Если мне надо вывести 2 списка одних и тех же сущностей, но с разной фильтрацией, то как при вашем подходе это сделать, если за этот список отвечает Vuex и он один на все компоненты?
Владимир Коротенко, нужели вы не видите жуткую костыльность вашего метода? Да он и не осуществим. Перечитайте мой исходный вопрос. Как вы при первом запросе узнаете, что необходимо для второго запроса?
Владимир Коротенко, такое ощущение, что вы либо мои вопросы не читаете, либо не понимаете, о чем вообще речь.
Повторю ещё раз. Есть архитектурное решение (и я его считаю глупым) - делать запросы к API через Vuex и результаты ответа хранить в сторе.
Почему я его считаю глупым: стор служит для того, чтобы несколько независимых компонентов имели доступ к одинаковым данным. А т.к. зачастую один и тот же эндпоинт API даёт разные ответы в зависимости от дополнительных параметров запроса, получается, что одновременный вывод одинаковых сущностей стора в двух независимых компонентах с разными фильтрами невозможен в принципе.
Про ваш совет делать всё на бэке, зачастую это невозможно, фронтендер редко когда может указывать бэкендеру, что он должен делать. А бывают случаи, что обращение к API вообще идет к стороннему сервису, на который в принципе никак не повлиять.
Также вариант получать избыточную информацию с бэка зачастую неосуществим, а если и осуществим, то в таком случае компонентам придется слишком много знать друг о друге, хотя это совсем ни к чему и решается простым способом - делать обращение к API без прослойки Vuex, который совершенно для другого.
Влад Токарев, Я и пытаюсь вас понять, но пока не вижу концепции, видно вы и сами не до конца понимаете.
Храните на фронте несколько наборов, в чем проблема?
Владимир Коротенко, концепцию я привел в своём первом вопросе.
Приведу ещё один пример: есть компонент, который выводит курс валют, на вход через пропсы он получает валюту-источник A и валюту-результат B.
Компонент со стороннего сервиса получает курс валют для пары.
Этот компонент выводится на странице несколько раз для неизвестных заранее пар валют.
Как вы решите эту задачу, используя прослойку Vuex?
А вот обращаясь напрямую из компонента в API, либо через прослойку, но где результат не сохраняется, а только возвращается, никаких проблем вообще не возникнет.
Влад Токарев,
Просто
Компонету передается 3 параметра currency1, cyrrency2, amount
Где то сверху возможно при создании компонента дергается Vuex (хотя можно и в компоненте при моунте)
Пока это все происходит крутится спинер ( условие пока не появится пара)
Когда появилось значение компонент получает обьект по фильтру: currency1, cyrrency2
Не знаю, зачем так делают, но предположу, чтобы иметь относительно одинаковый вариант получения данных, независимо от компонентов. Если с сервера запрашиваются данные об авторизированном пользователе или еще что-то, что не подразумевает изменения в зависимости от параметров запроса, то наверное логично делать это через экшны стора. Но вот списки, которые подразумевают фильтрацию и пагинацию вообще только проблемы создают. Например, компонент берет список из стора и отображает его. Потом мне понадобилось в попапе те же сущности вывести, но с другой фильтрацией - все - список первого компонента затерся вторым. Так что с такой практикой надо очень аккуратно.
У нас на работе изначально пошли по пути данных в сторе, потом это выпилили.
Еще минус в том, что данные с сервера в сторе реактивные, хотя для данных, полученных с сервера это обычно не требуется и влияет негативно на производительность. В случае использования composition api такие данные лучше хранить в shallowRef сущности и обновлять ее целиком при получении новых.
Средний
Средний
