Vuex и работа с модулями.

[QoreCode]

Господа, доброго времени суток. На своём проекте я использую самописную rest api на бэке и vue + vuex на клиенте. В поисках оптимизации я решил добавить в api поддержку выборки связанных сущностей, к примеру гет запрос пользователей может заодно получить связанную сущность заданий:
some-api.com/user
{
properties:{name: "Vasia"},
extend:['issue']
}
результатом данного запроса будет:
{
entities:[
{id:2, name: "Vasia"},
{id:5, name: "Vasia"}
],
extends:{
issue:[
{id: 5, userId:2, title:"some title 5"},
{id: 7, userId:2, title:"some title 7"},
{id: 9, userId:5, title:"some title 9"}
]
}
}

Так же расскажу о структуре своего стора. Он у меня модульный и под каждую сущность отведен модуль для работы с ней. Для примера у user есть user-module, у issue есть issue-module. Таким образом я разделяю логику запросов и выборок разных сущностях по модулям и мне легче ориентироваться в приложении... все модули миниатюрные и отвечают только за одну сущность.

Так вот, ранее (до появления метода extend) я делал подобное 2мя отдельными запросами которые отлично себя чувствовали в разных экшенах модулей user-module и issue-module. Сейчас же мне кажется неправильным вызывать экшен модуля user-module, и в запросе так же указывать выборку заданий, которые позже нужно закомитить в issue-module.

Я вижу несколько решений данной пробелмы:
1. Вызывать экшен loadUserWithIssues в родительском модуле. Но я боюсь что это в корне не верно и пытаться выстроить иерархию модулей только для запросов кажется мне глупостью
2. В каком-то компоненте (скажем компоненте страницы) отдельно послать запрос, получить данные и отправить их на обработку/сохранение в соответствующие модули. Этот вариант мне нравится больше, но не выходит ли данный подход за пределы конецпции vuex?

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

[SuperZen]

https://hasura.io/

потом пишешь запросы в виде )

user {
  firstname
  lastname
  etc
  issues {
    id
    etc
    aggregation(by: CONDITION)
    pagination {
      totalpages
      etc
    }
    comments {
      id
      title
      etc
    }
  }
  something(id: XXX) {
   more
  }
}

вложенные select, update, insert, вах вах вах

[QoreCode]

Да, интересная штука, я обязательно ее разберу, ибо имел позитивный опыт с mobx, если это нечто подобное ток исчё и с фишками для клиента - то это круто! Но кину свои опасения по поводу их способа возврата данных:
Есть риск дублирования данных и потенциальных проблем с их устареванием... как пример:
Пользователь зашел на свой дашборд и я выгрузил пользователя со всеми ЕГО задачами в сущность user модуля user-module. Потом пользователь перешел на страницу "все задачи" и они загрузились в модуль issue-module. Дальше пользователь отредактировал задачу... в этот момент я должен помнить что задачи есть не только в модуле issue-module, но и в сущности user модуля user-module и при необходимости нужно будет обновить данные уже в 2х местах. Я согласен что проблема кажется надуманной и ничего не мешает просто заново загрузить данные когда они потребуются, но в таком случае получается что дополнительная загрузка сущности user будет выполнена исключительно для загрузки и обновления issue... ну или придется проверки вставлять и если сущность user уже существует тогда нужно обновить у нее issue...

В любом случае сейчас я не могу ее заюзать ибо бэк в какой-то степени уже готов и не горю желанием его переписывать. Я в раздумиях склоняюсь к тому что нужно переорганизовать стор...

[SuperZen]

Пользователь зашел на свой дашборд и я выгрузил пользователя со всеми ЕГО задачами в сущность user модуля user-module. Потом пользователь перешел на страницу "все задачи" и они загрузились в модуль issue-module. Дальше пользователь отредактировал задачу... в этот момент я должен помнить что задачи есть не только в модуле issue-module, но и в сущности user модуля user-module и при необходимости нужно будет обновить данные уже в 2х местах.

это про состояние на клиенте? )

Я согласен что проблема кажется надуманной и ничего не мешает просто заново загрузить данные когда они потребуются, но в таком случае получается что дополнительная загрузка сущности user будет выполнена исключительно для загрузки и обновления issue... ну или придется проверки вставлять и если сущность user уже существует тогда нужно обновить у нее issue...

лучше сделать на сервере вебсокет и при событии create, update, delete посылать объект события на клиент, реализация типа комнат в чате /:user/:issue и хранить все объекты на клиенте в нормализованном виде

user :{
id
}

issue: [{
id
user_id
}]

Я в раздумиях склоняюсь к тому что нужно переорганизовать стор...

лучший код еще не написан... неизвестно что там у вас за сервер, если вы используете vuex не только для ssr, а еще как rest api, можно это тоже разделить. Вот, например, https://docs.nestjs.com/ можно посмотреть как у них это все организовано. Не обязательно все там понимать, можно сверху посмотреть на архитектуру. Про graphql почитайте, возможно это именно то что ищете ))

[QoreCode]

это про состояние на клиенте? )

Да, речь идёт исключительно о клиенте. Rest api написана на шарпе и не имеет никакой связи с клиентом. Всё по канонам.

хранить все объекты на клиенте в нормализованном виде

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

[SuperZen]

не про vue, но в целом это все тоже будет на пути:
https://www.apollographql.com/blog/d...ment-solution/

особенно эти топики:
State management infrastructure can account for up to 50% of the work in building a client-side application
Building data layer infrastructure is expensive

лучше делать как можно проще )

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

с чего начать интерфейс: https://storybook.js.org/
потом обложиться eslint'ами, по всем фронтам, а то если будет несколько разработчиков, это в скором времени превратится месиво )