jenya7771, sequelize просто пытается сделать SELECT с GROUP BY, где перечислены поля в свойстве group.
Вы не получите таким подходом список идентификаторов пользователей с коллекцией сообщений. Два рабочих подхода я вам уже описал выше, если нельзя менять структуру БД.
jenya7771, Ну всё правильно! В group by дожны попадать ВСЕ поля, которые попадают между SELECT и FROM в чистом виде (т.е. не участвуют в функциях агрегации).
v-model - это же просто синтаксический сахар для одностороннего биндинга :value и обратного события @input, по которому и меняем в родителе исходное значение. Никто не мешает написать раздельно и в обработчике для @input нагородить свой огород.
jenya7771, ну это уже денормализация, иногда такое нужно для ускорения выборок, но тогда нужно больше места в БД и больше усилий для поддержания соответствия данных друг другу.
можно попробовать донастроить belongsToMany от пользователей к сообщениям с указанием messengers как промежуточной таблицы и сделать users.findAll с include на messengerMessages используя эту ассоциацию.
Либо получить запросом как у вас (но без group) по messengerMessages, а потом лодашем или чем хотите сделать плоский массив сообщений внутри каждого пользователя.
lodbrock, Читаемость лучше, когда разметка компонента вместе вся, а не куски вперемешку с кодом. В чем проблема? В условном рендере? v-if/v-show вам в помощь.
А ничего, что obj по ветке else будет инициализирован позже, чем функция закончится? Асинхронность то учитывать надо!
Почему нельзя сделать функцию асинхронной и сделать что-то типа:
massef, нет, под удаленным я понимаю какое-то хранилище на бэкэнде/в облаке. Vuex - хранение общего состояния в приложении с поддержкой реактивности. LocalStorage - хранилище (не очень большое) в браузере, которое используется для сохранения параметров сессии, к примеру. Его не надо использовать как основное хранилище задач!
А зачем в LocalStorage? Ну ладно бы там хранить что-то промежуточное или кэш некоторый на случай ухода и возвращения пользователя. А почему нельзя сохранять в фоне в настоящее хранилище ремотное реальные изменения в задачах?
1. Должно ли сохраняться в каком-то постоянном хранилище изменение статуса задачи сразу после перетаскивания?
2. В сторе должны лежать сами задачи вкупе со статусами как свойством любой задачи, от коих статусов и зависит куда на доске попадет задача. Вы же не хотите сказать, что у Вас всего один god-компонент, в котором ВСЁ сразу и нет других компонентов, которым нужно знать про таски?
Вы не получите таким подходом список идентификаторов пользователей с коллекцией сообщений. Два рабочих подхода я вам уже описал выше, если нельзя менять структуру БД.