On this page
Select filter
Add dropdown filters that narrow the table by a single value (e.g. status, category). Each filter is a select whose choices come from a proc and whose selection is applied via a filter proc.
Settings#
There is no table-level switch to disable select filters; omit select_filter definitions if you don’t want any.
Per-filter definition:
| Option | Type | Description |
|---|---|---|
filter_id |
Symbol | Unique id for the filter; the request param is :"#{filter_id}_filter" (e.g. :status_filter). |
choices |
Proc | ->(scope) { ... }. Called with table.unfiltered_rows; must return an array of values shown in the dropdown. |
filter |
Proc | ->(scope, value) { ... }. Called when a value is selected; must return the filtered scope. |
Class settings#
Define filters with select_filter in your table class. Each definition registers the filter param and a filter method.
class UsersTable < RapidUI::Datatable::Base
extension :select_filters
select_filter :status,
choices: ->(scope) { scope.distinct.pluck(:status).compact.sort },
filter: ->(scope, value) { scope.where(status: value) }
select_filter :role,
choices: ->(scope) { scope.distinct.pluck(:role).compact },
filter: ->(scope, value) { scope.where(role: value) }
columns do |t|
t.integer :id
t.string :name
t.string :status
t.string :role
end
end
Instance settings#
Select filter definitions are class-level. At runtime you only control which filters are built in the UI. The selected value for each filter comes from the request params.
Adapters#
No adapters are necessary since the choices and filter procs perform the ORM work themselves.
Controls#
Each select_filter call registers a control named :"#{filter_id}_filter" (e.g. :status_filter, :role_filter). Add those to your placement (e.g. header_controls) and each is built individually.
self.header_controls = [ :search_field_form, :status_filter, :role_filter ]
The datatable will call build_status_filter, build_role_filter, etc., when rendering the header; no separate “build all” call is needed.