Комментарии 3
Для того, чтобы грамотно организовать очередность, решено использовать, давно доказавшую свою полезность, библиотеку RxJS
Ясно. Какие громкие слова.
Её прелесть в том, что она помогает легко и без особых взрывов мозга представить многие явления как потоки событий и предоставляет множество способов с этими потоками взаимодействовать
Ясно. Вообще без взрывов мозга, ага.
чем больше опций для фильтров, тем больше идет запросов количества записей, исполнение каждого из которых, если учесть количество подтягиваемых таблиц и их размер, может занять значительное время.
а как вообще у вас организована фильтрация?
почему количество «опций фильтра» (кстати, что это?) влияет на количество запросов?
Добрый день.
Довольно стандартно. Есть 2 вида блоков. В блоках первого типа пользователь может выбрать любые опции из заранее заготовленного списка. Допустим, есть блок, посвященный марке автомобиля, и опции «Volkswagen», «Skoda», «Ford». В блоках второго типа пользователю предоставляется либо поле для ввода, либо заготовленные виджеты, к примеру, для ввода даты, промежутков дат и т.п. Он выбирает свойство, по которому хочет добавить условие, к примеру, «Дата выхода модели» и указывает любое желаемое значение. При этом для каждого из аспектов он может указать любое количество значений. При этом есть ещё возможность инвертировать поиск по некоторым атрибутам…
В итоге все введенные условия собираются, аккумулируются и передаются на сервер.
Для каждой опции («Volkswagen», «Skoda» или «Ford») из каждого блока первого типа мы подтягиваем количество записей, подходящих именно под эту опцию и под все остальные введенные фильтры. Запрос исполняется на уровне базы, поэтому для каждой из опций приходится делать свой запрос, т.к. меняются условия. Поэтому у нас столько запросов, сколько и опций. Можно, конечно, попробовать поработать с запросом и группировкой по опции, но пока нет необходимости.
Очень надеюсь, что расписал понятно.
а как вообще у вас организована фильтрация?
Довольно стандартно. Есть 2 вида блоков. В блоках первого типа пользователь может выбрать любые опции из заранее заготовленного списка. Допустим, есть блок, посвященный марке автомобиля, и опции «Volkswagen», «Skoda», «Ford». В блоках второго типа пользователю предоставляется либо поле для ввода, либо заготовленные виджеты, к примеру, для ввода даты, промежутков дат и т.п. Он выбирает свойство, по которому хочет добавить условие, к примеру, «Дата выхода модели» и указывает любое желаемое значение. При этом для каждого из аспектов он может указать любое количество значений. При этом есть ещё возможность инвертировать поиск по некоторым атрибутам…
В итоге все введенные условия собираются, аккумулируются и передаются на сервер.
почему количество «опций фильтра» (кстати, что это?) влияет на количество запросов?
Для каждой опции («Volkswagen», «Skoda» или «Ford») из каждого блока первого типа мы подтягиваем количество записей, подходящих именно под эту опцию и под все остальные введенные фильтры. Запрос исполняется на уровне базы, поэтому для каждой из опций приходится делать свой запрос, т.к. меняются условия. Поэтому у нас столько запросов, сколько и опций. Можно, конечно, попробовать поработать с запросом и группировкой по опции, но пока нет необходимости.
Очень надеюсь, что расписал понятно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Оптимизация страницы с использованием RxJS и Expression Tree