Когда не использовать vuex | redux | flux?

Question

[Руслан]

Здравствуйте!

Возник вопрос, использовать или не использовать библиотеки управления состоянием на уровне всего приложения.

Сценарии работы с данными в приложениях (spa или web?) могут быть разными, но я их условно разделил на 2:

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

Второй: у нас данных очень много (миллионы объектов на сервере), и мы их все не загружаем, а делаем запрос, который возвращает максимум несколько десятков объектов. Так вот вопрос: нужно ли в этом случае помещать их в хранилище и работать с ними через хранилище. Меня смущает вот какой момент: пользователь же может одновременно открыть два компонента, которым нужна разные наборы данных с сервера, а у нас в хранилище только один, не лучше ли каждый раз, когда открывается очередная страница, в компоненте, который отображает список, запрашивать данные с сервера?

Вот что еще осложняет раздумья: если мы пользуемся vue или react, то у нас приложение – SPA, даже если пользователь его открывает в браузере. И если у нас в приложении предусмотрено что одновременно можно открыть только один экземпляр списка с нашими объектами, то тогда можно использовать хранилище состояний и обновлять его с сервера каждый раз, когда пользователь меняет фильтры. А если пользователь откроет в разных вкладках браузера разные страницы этого приложения, то, по сути, это будут разные экземпляры приложения, в каждом из которых будет свое состояние. Логично?

И все-таки вопрос: в каких случаях данные с сервера хранить в хранилище состояний (vuex|redux) нужно, а в каких – нет?

Comments

[Игорь]

Второй: у нас данных очень много (миллионы объектов на сервере), и мы их все не загружаем, а делаем запрос, который возвращает максимум несколько десятков объектов. Так вот вопрос: нужно ли в этом случае помещать их в хранилище и работать с ними через хранилище. Меня смущает вот какой момент: пользователь же может одновременно открыть два компонента, которым нужна разные наборы данных с сервера, а у нас в хранилище только один, не лучше ли каждый раз, когда открывается очередная страница, в компоненте, который отображает список, запрашивать данные с сервера?

Как я решал подобную задачу.

Конечно же не реально загрузить 5 000 000 записей в хранилище, звучит даже бредово.

В качестве фронта использую Nuxt
Данные загружаю по API напрямую в компонент, в методе asyncData
например первые 10 записей, а далее limit offset

А что мешает одновременно использовать 2 способа?

[Jhn Doe from by]

Игорь,

В качестве фронта использую Nuxt

причем тут вообще nuxt? (вопрос риторический)
не нужно советовать то о чем не просят, nuxt ему ничего не даст

[Игорь]

Дорогой Jhn Doe from by, покажите где я даю совет?

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

[Jhn Doe from by]

Игорь, почему то показалось что вы сказали возьмите nuxt. Если вы конечно не отредактировали ответ

[Игорь]

Jhn Doe from by, Нет, я действительно хотел раскрыть свои действия, не более.
Я прекрасно понимаю, что Nuxt не имеет ни какого отношения к вопросу.

Answer 1

[Vlad_Murashchenko]

Все просто.
1) состояние относится к какому-то конкретному компоненту, который сам несёт ответственность за CRUD с данным состоянием - используй локальное состояние.
Пример: список каких-то элементов, мы ведь не захотим отобразить или поработать с элементом из этого списка где-то в другой части приложения, это ведь бред какой-то, хотя дизайнеры могут придумать всякие. И если они придумают то прийдется подымать это состояние выше или выносить в глобальное.
2) если же состояние используется в разных компонентах которые не имеют прямого отношения друг к другу, тогда удобнее использовать глобальное состояние чтобы удобно внедрять его в нужные компоненты и предоставлять им интерфейс для работы с ним.
Пример: сервер предоставляет нам объект юзера в котором есть статус, имя, фотография, какие-то ещё данные. Статус отображается и редактируется в одном компоненте, имя с фотографией отображается в другом, а редактируется в какой-то вообще отдельной форме со своим состоянием. Здесь нам бы пришлось держать данное состояние где-то очень высоко и далеко от компонентов которые им управляют, глобальное состояние упрощает работу с подобными состояниями

Answer 2

[Robur]

Посмотрите как работает GraphQL + Apollo client. Особо внимательно про нормализацию и кеширование на клиенте. Там уже люди очень серьезно подумали на проблемами которые вы озвучили (и другими тоже) и много чего хорошего придумали - грех не воспользоватся. Если не самими технологиями то подходами и решениями.

Answer 3

[Андрей К]

Компонент загружает данные с сервера, которые ему нужны, потом он с ними работает и из стирает сборщик мусора.

Хранилища нужны для отслеживания общего состояния приложения (или модуля), то есть, если это обычный CRUD, то далеко не факт, что есть смысл этим данные хранить в общем состоянии.

И не нужно путать с кешированием, так как это разные задачи.

Comments

[Jhn Doe from by]

глобальное хранилище т.е. global store можно конечно юзать в виде кеширования. Но я бы не советовал это делать, да и работать оно будет пока вкладку не закроешь

[Андрей К]

Jhn Doe from by, есть и другие проблемы. Смысл глобального хранилища в реактивности, отсюда там есть оврехед, поэтому, для кеширования можно просто создать мапу или еще что-то и вставлять ее куда нужно... Или, если на долго, то Local Storage.

Answer 4

[Jhn Doe from by]

если мы пользуемся vue или react, то у нас приложение – SPA, даже если пользователь его открывает в браузере.

вы точно понимаете что такое spa? мне ничего не мешает юзать vue или react вне spa

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

логично, где вопрос?

И все-таки вопрос: в каких случаях данные с сервера хранить в хранилище состояний (vuex|redux) нужно, а в каких – нет?

а) данные нужно пробросить из одного компонента в другой, не имея при этом связанно цепочки, либо она слишком длинная, данные пробрасываются, чтобы обновить локал стор какого-то компонента
б) хочу настроить серверный рендер шаблонов с какими-то динамическими данными(из БД). Там как раз и используется global store для этого

Так вот вопрос: нужно ли в этом случае помещать их в хранилище и работать с ними через хранилище.

5млн объектов из базы в глобал сторе? НЕТ
первые 20-30 можно поместить, далее пробросить их компонентам страницы
следующие 4.9млн загружать в локал стор, все.

Меня смущает вот какой момент: пользователь же может одновременно открыть два компонента, которым нужна разные наборы данных с сервера, а у нас в хранилище только один, не лучше ли каждый раз, когда открывается очередная страница, в компоненте, который отображает список, запрашивать данные с сервера?

не понял вопроса, кони-люди смешалось вообще все...
2 компонента на странице. Каждому нужны данные с разных ресурсов?
ну дак и загружайте их в локал сторы этих компонентов. Запрашивайте данные с сервера, в чем проблема?

которым нужна разные наборы данных с сервера, а у нас в хранилище только один

global store (vuex, redux) может хранить одновременно хоть сотню наборов
И да читайте документацию по redux, там это все есть

Comments

[Vlad Osadchyi]

локал стор какого-то компонента

Имеется ввиду state компонента?)

[Jhn Doe from by]

Vlad Osadchyi, для реакта да, для вуе по-моему там data это называлось (год не писал фронт энд, уже подзабыл много)

[Игорь]

Центральное хранилище vuex, не имеет ни какого отношения к localStorage

[Игорь]

Ссылка по теме

Answer 5

[Ivan Driuk]

Если данные обновляются с сервера без перезагрузки страницы, то всегда хранить в редакс. Миллионы значений за раз не загружать )). Если разным компонентам нужны разные данные, то получаем их в стейт редакса, а уже оттуда коннектить к компонентам. Итого, редакс не использовать тогда, когда вся логика и работа с данными на бекенде. Или когда хочется усложнить себе жизнь обрабатывая/сохраняя логику и данные внутри компонентов.

Comments

[Андрей К]

Зачем хранить в Redux данные, которые нужно для одного компонента?

[Ivan Driuk]

Скажем так, есть ситуации, когда данные нужны только этому компоненту и только сейчас, а когда компонент исчезнет, то данные тоже должны исчезнуть. В таких ситуация действительно лучше сделать локальный стейт компонента и хранить там эти временные данные. Такая ситуация может быть , если делается форма и если юзер с нее ушел, то все служебные данные , типа ошибок валидации и лоадеров должны исчезнуть.