Customizing the SearchApp component

The SearchApp (see also the beheerder page about the search page) is a search-and-filter component technically built as a standalone, reusable front-end component (React, from i-Reserve’s shared component library). This means that — besides the self-service options an administrator has in the configuration screen — more is possible on a custom basis than what is configurable by default. This page describes what is technically possible; implementing it is custom work you have Teqa (or an implementation partner with template access) set up.

Where the configuration lives

A SearchApp instance is invoked from a page template with a single function call, per sector (Events, Boat rental or Meeting rooms). The filters an administrator adds via “Manage search filters” are written into that call automatically; everything around it (display options, extra filter types, map view, sort options) is added by hand in that same configuration.

Filter types: more than the administrator sees

The “Manage search filters” admin screen always generates the same filter type: checkboxes whose options are derived automatically from the data (a “checkbox group”, with auto-derived options). The component itself additionally supports:

• a free-text field (search by description);
• a single-value dropdown (“select”);
• a date range, a single date, or a time-slot/period picker;
• a fully custom filter function for cases that don’t fit the standard types.

These extra types are not visible or editable in the admin screen; they are only added directly in the configuration by a developer.

Search on a map

Besides a list, the component can also show results on a map: a list/map toggle, with a marker per result, automatic clustering of results at the same location, and automatic zoom to fit the visible results.

You set this up via two options in the same configuration where the filters live: views (add 'map' next to 'list') and map. The main map fields:

• center — required, the map’s starting position (latitude/longitude).
• coordsField — required, the name of the result column holding the coordinates as text “latitude,longitude”, for example “52.3676,4.9041”.
• zoom — optional, starting zoom level.
• mapId — optional, enables Google Maps’ newer marker style.
• clusterSameLocation — optional, on by default: results at the same location are grouped into a single marker with a count.
• fitBounds — optional, on by default: the map automatically frames itself so all visible results are in view.
• getMarkerIcon / renderInfoWindow — optional, for a custom marker style or custom info-window content per result.

map: {
  center: { lat: 52.37, lng: 4.90 },
  zoom: 8,
  coordsField: 'COORDS'   // column with e.g. "52.3676,4.9041"
},
views: ['list', 'map'],
defaultView: 'list'

The coordinates need to be present as a column in the search page’s results. For objects, i-Reserve already records a latitude and longitude internally, but as two separate fields — the map view expects them as a single combined text value per result instead. For other result types (for example standalone locations without a linked object), i-Reserve doesn’t record coordinates yet. In both cases, the first step is for a developer to add a column on the search results API side that returns the coordinates as one combined value, and reference that column name in coordsField.

Custom result rendering and sorting

Besides the default result display, a developer can supply a fully custom layout per result, add custom sort options (for example by price or popularity, if available as data), and decide what happens when a visitor clicks a result (for example jumping straight into the booking flow instead of showing a detail page first).

What can the administrator do, and what is custom work?

Would you like one of the custom options set up? Contact Teqa — see also the admin page about the search page for what you can already configure yourself as an administrator.