[laimas]

по сути именно и изучаю как они внутри работают

Ну тогда и вопрос не должно быть. Шутка.

Меня смущает тип данных filter-by-house-type, filter-by-bedrooms, ... то есть речь о скорее всего идет о недвижимости. Я как раз сейчас работаю над заказом для агентства недвижимости. У них два десятка риэлторов, и каждый вынужден получать табличные данные такими, какие установлены в единой конфигурации. Для администрирования это крайне неудобно, а тасовать полученные данные на клиенте используя фильтрацию, это бессмыслица, так сервер вынужден отдавать все скопом, а не только то, что нужно, а если предполагается и редактирование табличных данных, то это усложнение как серверной, так клиентской части кода. Да и вывод табличных данных для администрирования не ради тасовать на клиенте делается, а все тики для работы.

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

Фильтр, а также и наборы для других представлений, как то сортировка, и т.д., уж никак не определяются как filter-by-house-type, filter-by-bedrooms. Поступая таким образом практически не возможно написать универсальное управление выводом, для которого выходными данными были бы только таблица и ее поля. Для каждой таблицы и ее полей придется писать свою "кочергу".

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

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

Остается в таблицу определяющую поля таблиц, которым разрешают/запрещают выбор для какого либо из наборов (отображение, фильтр, сортировка и т.д.), указать тип данных, по которым клиент и будет строить поля для выбора параметров фильтра, сортировки...

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

А вот для пользователей на страницах, которым тоже будет доступен фильтр вывода данных, определяется иной сервис. Фильтр, это все таки не тасовать полученный набор на странице, а получение данных только отвечающих фильтру. Но так как вывод данных в любом случае будет постраничный, а на каждой из них пользователя может что-то заинтересовать, то удобно было бы делать выборку таких объектов на каждой странице и заносить их в набор. В этом случае можно запрашивать у сервера только те данные, которые заинтересовали пользователя, и с ними уже проводить различные операции - сортировать, удалять из набора и т.д..

Я это делал исходя из задач, которые определяются риэлтором для работы с данными, и сервисом для клиента. Какова конечная задача вашего фильтра я не знаю, если ради "крутить/вертеть" данными на странице, ну красиво, но а толку от этого? Для галереи, и подобного контента это и хорошо, да и полезно будет, а если недвижимость, то вряд ли целесообразно.