я вообще не вижу, зачем тут эвент бас. в компоненте, отображающем данные, зависящие от города делаем watch на город (он же в сторе), в этом вотче выставляем статус загрузки данных, проверяем, есть ли в сторе данные для города, если нет, вызываем экшен загрузки, по завершению проверки и загрузки - выставляем статус загрузки в "загружено".
Александр Панков, менять город не мутацией, а экшеном, в экшене вызывать мутацию и экшены для заполнения других сторов. Это самый простой вариант.
Есть вариант похуже - вызывать экшены заполнение сторов в компоненте смены города.
Есть вариант посложнее - вместе с подключением "дополнительных" сторов вешать плагины для отслеживания мутаций текущего города и в плагине вызывать обновление стора. что-то типа инверсии зависимости тогда получится.
Кажется основная проблема в том, что ты не прочитал про то, что из модуля можно обратиться к корневому хранилищу, соответственно из него - к состоянию/мутациям/действиям других модулей
Зачем под каждый город свой стор? просто сделай геттеры, которые в зависимости от текущего города будут выдавать отфильтрованные данные. ну или из api перезаполняй стор, или что там тебе удобнее будет.
Глеб Старков, да пусть перетаскивается вместесо ссылкой. просто чувствительная область для перетаскивания пусть будет не весь див-контейнер, а какая-нибудь ручка, по типу такого:
baranovstas, await ничего не передает, это сахар синтаксический.
грубо говоря вызовом then(func) ты устанавливаешь внутреннее свойство объекта промис, указываешь ему колбэк, который будет вызван в момент вызова resolve, при этом в resolve ты передаешь параметр, который будет передан в колбэк.
вот ооочень грубая реализация, без защит и поддержки цепочек: https://jsfiddle.net/m601Lu3v/
вместо кода приведен какой-то надерганный из разных мест копипаст. Скорее всего дело в том, что в набор движений записывается только одна строка - последняя после перебора ТЧ.
FanatPHP, по какому индексу? по дефолту индекс только на примари кей есть, больше информации у нас нет. если есть составной индекс на user_id, event_id, то все равно будет полный скан индекса, но таблицы будут предсортированы, да, если на event_id, user_id - то да, обе подтаблицы будут почти наверняка будут предсортированы, скорее всего будет два частичных сканирования индекса и мердж джоин (один цикл по двум таблицам одновременно). но при наличии такого индекса и вариант с подзапросом также отработает хорошо - скорее всего там будет одно частичное сканирование индекса + цикл агрегации.
При отсутствии индекса или при несоставных индексах - вариант с подзапросом будет лучше.
Все очень зависит от того, как это дело воспримет планировщик запросов СУБД. Повторюсь - при использовании подзапроса у него "пространства для маневра" просто меньше. Вот тут неплохо описаны различные способы выполнения джоинов: https://docs.microsoft.com/ru-ru/sql/relational-da...
>я, блин, такого словоблудия давно не видел
словоблудие началось с "почему не джоином?". тут-то мои навыки анализа затыков в производительности sql запросов и пригодились.
FanatPHP, мердж джоин и нестед лупс - это способы получения результирующей таблицы из двух соединяемых подтаблиц на условно "физическом" уровне. это в sql профайлере надо смотреть. не уверен, что в mysql explain это покажет, а вот в postgres и ms sql - показывает. первый требует предварительную сортировку обеих таблиц по предикату соединения, второй - это цикл в цикле. соотвтетсвенно, планировщик СУБД оценивает, сколько нужно времени на сортировку двух таблиц + цикл и на цикл в цикле и выбирает вариант соединения. при неправильной статистике по данным может быть больно. В варианте с подзапросом планировщик всегда выберет сортировку (одну!) + цикл. Это почти наверняка будет лучше (и 100% не хуже), причем более стабильно (планировщик не сможет ошибиться).
