Skip to main content

​
Filtering

​
Disabling filtering

Disable filtering without any code in the field settings in the Forest UI. That setting only hides the filter in the UI: the API still accepts filters on the field. Use the method below to make the back-end reject them too.
The disableFieldFiltering method removes filtering for end users on a column, or on a many-to-one or one-to-one relationship. It needs @forestadmin/agent 1.107.0 or later, or forest_admin_rails 1.45.0 or later.
The Forest UI no longer offers the field as a filter. The back-end rejects any filter on it that comes from the UI or the API, including UI segments and saved views. On a relationship, the rejection covers every filter that goes through it: with author disabled, the back-end rejects a filter on author:name.
Saved views and UI segments that already filter on the field stop working. Before you disable filtering on a field of an existing project, check which views and segments use it.
Your customizations keep filtering on the field:
  • A disabled column remains usable as the key of a custom relationship.
  • Code segments keep filtering on a disabled column or through a disabled relationship.
  • The search bar keeps reading a disabled column, and searching through a disabled relationship.
Limitations:
  • The method accepts a column, a many-to-one or a one-to-one relationship. On a primary key, a one-to-many or many-to-many relationship, or a polymorphic relationship, the back-end fails to start.
  • Disabling a many-to-one relationship leaves its foreign key filterable: with author disabled, users still filter on authorId. Disable the foreign key too to remove both.
  • Pass the field’s original name. On a field renamed with renameField (Node.js) or rename_field (Ruby), use the name it had before the renaming.

​
Substitution

Operation substitution serves two purposes:
  • Performance: provide a more efficient way to perform a given filtering operation
  • Capabilities: enable filtering on a computed field or other non-filterable fields
Use the replaceFieldOperator method to unlock the operators.

​
Emulation

Filtering emulation allows making fields filterable automatically. It is a convenient way to get things working quickly for collections that have a low number of records (in the thousands at most).
This emulation forces the back-end to retrieve all the collection records and compute the field values for each one of them. As a consequence, filtering emulation performance cost is linear with the number of records in the collection, so activate it sparingly and with great care.

​
Sorting

Depending on the data source, not all fields may be sortable, or you may want to change how the native sorting works. Use the replaceFieldSorting and emulateFieldSorting methods to change a single column’s sorting behavior.

​
Substitution

Provide replacement sort clauses. In this example, we’re telling Forest “When a user sorts by full name, I want to sort by the last name, and then by the first name”.
Another very common reason is performance. For instance, with auto-incrementing ids, sorting by creationDate is equivalent to sorting by the primary key in reverse order. Using sort substitution where needed can save you from adding many indexes to your database.

​
Emulation

Sorting emulation allows making any field automatically sortable. It will sort records by lexicographical order. It is a convenient way to get things working quickly for collections that have a low number of records (in the thousands at most).
This emulation forces the back-end to retrieve all the collection records and compute the field values for each one of them. As a consequence, sorting emulation performance cost is linear with the number of records in the collection, so activate it sparingly and with great care.