feat: Filters + Boosts

[jbottigliero]

The general approach here is to allow users to specify data.attributes.globus.search.filters as partial GFilter definitions, then using that object to generate a UI control. The UI control can then be further customized by providing a ui member to the object. The ui member has a few well-known properties (type, label, and description) the rest are spread down to the most relevant Mantine component rendered based on the GFilter.type mapping.

• This leaves room to allow users to hard-code value/values to act as constant filters.
• Splitting ui should allow for extending functionality in the future.

Example 1: match_any / match_all

{
  "field_name": "example_field",
  "type": "match_any" // or, "match_all"
}

• Will render a <TagsInput /> (https://v8.mantine.dev/core/tags-input/)

Example 2: range

{
  "field_name": "number_of_states_in_flow",
  "type": "range",
}

• Will render a <RangeSlider> (https://v8.mantine.dev/core/range-slider/)

In this case the default <RangeSlider> min/max are probably not representative of your data, so they are best provided using the ui member:

{
  "field_name": "number_of_states_in_flow",
  "type": "range",
  "ui": {
     "min": 1000,
     "max": 10000,
     "step": 500
   }
}

Example 2B: Dates + Date Time Fields

Dates and Date Time fields are examples of data types that are not suitable for just a simple of GFilter.type to a control. To allow further customization of the rendered control a more specific ui.type can be provided.

{
  "field_name": "number_of_states_in_flow",
  "type": "range",
  "ui": {
     "type": "date"
   }
}

• Will render a <DatePicker> with a type of "range" (https://v8.mantine.dev/dates/date-picker/#dates-range)

{
  "field_name": "number_of_states_in_flow",
  "type": "range",
  "ui": {
     "type": "datetime"
   }
}

• Will render two <DateTimePicker> components, one representing the from value, the other the to value (https://v8.mantine.dev/dates/date-time-picker/)

Screen.Cast.2026-04-15.at.1.28.03.PM.mp4

---

All of this "works", but before I go much further I'm trying to determine if there is a better way to document and enforce this functionality (thinking along the lines of "previewing"/Storybook); This GFilter.type to control mapping could be seen as fairly generic and useful outside the context of this portal...