mirror of
https://github.com/mauriceboe/TREK.git
synced 2026-10-18 21:16:47 +00:00
feat(plugins): search plugins can answer the place search as you type
A searchProvider plugin can now implement an optional suggest() beside search(). Its places then show up in the place search's typed-ahead list, after the core suggestions and marked with the plugin's name, on desktop and phone. An index that cannot take a request per keystroke leaves it out and keeps answering the full search only. The child reports which functions each hook object carries at load, so GET /api/plugin-search/suggest only asks the plugins that implement suggest: from the second character, three rows at most across all of them, 800 ms to answer. The feed marks plugins holding hook:search-provider and the client only asks the route while one is installed. A plugin row carries its whole place, so picking it skips the details lookup, which knows no plugin id. The phone's search results now name their source as the desktop ones do, and the desktop dropdown scrolls instead of running past the dialog. Addresses discussion #2221.
This commit is contained in:
@@ -225,7 +225,7 @@ skipped, never fatal):
|
||||
| `mapMarkerProvider` | ≤200 markers per provider |
|
||||
| `warningProvider` | ≤20 warnings per provider, each message ≤300 chars |
|
||||
| `placeDetailProvider` | ≤12 items per provider |
|
||||
| `searchProvider` | ≤20 places per provider, 2 s to answer |
|
||||
| `searchProvider` | `search`: ≤20 places per provider, 2 s to answer. `suggest` (optional): ≤3 places in the dropdown across all providers, 800 ms to answer |
|
||||
| `poiCategoryProvider` | ≤4 declared categories per plugin; ≤60 places per answer (inside `bounds` only), ≤6 detail rows per place, 8 s to answer |
|
||||
| `photoProvider` | ≤60 photos per page |
|
||||
| `calendarSource` | ≤500 events per source per request |
|
||||
@@ -413,6 +413,10 @@ The SDK tooling in this repo is MIT. Your plugin is your own code under your own
|
||||
|
||||
The `searchProvider.search` request can include `category` and `bounds` (south, west, north, east). Search within that rectangle for the category; `query` remains a readable category query and `near` its centre, so existing providers continue to work. These optional fields are absent on older hosts and ordinary name searches. The host validates and filters coordinates, namespaces IDs, and applies the exact route corridor after combining sources. The existing permission and two-second hook timeout still apply.
|
||||
|
||||
### Suggestions while the user types
|
||||
|
||||
`searchProvider.suggest` is optional. Implement it only when your index can take a request per keystroke, typically one you keep in your own database; your rows then appear in the place search's dropdown while the person types, after TREK's own suggestions and labelled with your plugin's name. It gets the same `SearchRequest` as `search`, from the second typed character on, with `limit` 3 and 800 ms to answer, and the dropdown keeps at most three plugin rows across all providers. A picked row is taken as it is, without a details lookup, so fill in address, website and phone right away. The host learns whether your hook has `suggest` when the plugin loads (a class method counts), and never calls it on a plugin without one.
|
||||
|
||||
### POI categories on the trip map
|
||||
|
||||
A plugin can add up to four chips of its own to the trip map's **Explore places** pill
|
||||
|
||||
@@ -517,6 +517,16 @@ export interface SearchProvider {
|
||||
* Called for an explicit search, not for every keystroke: an external index has rate
|
||||
* limits, and a request per typed letter would spend them on words nobody finished. */
|
||||
search(request: SearchRequest, ctx: PluginContext): Promise<SearchResultPlace[]>;
|
||||
/** Optional: places for the query while it is still being typed, shown under the
|
||||
* core suggestions in the place search's dropdown. Implement it only when your index
|
||||
* can take a request per keystroke, such as one you keep locally; leave it out and
|
||||
* your places appear once the search is run, as before.
|
||||
*
|
||||
* Called from the second typed character on, with `limit` 3, and given 800 ms. The
|
||||
* host keeps at most 3 rows across every provider, so return your best few, and
|
||||
* `near` is where the person is planning. Picking a row takes it as it is, so fill in
|
||||
* what you know (address, website, phone) here rather than later. */
|
||||
suggest?(request: SearchRequest, ctx: PluginContext): Promise<SearchResultPlace[]>;
|
||||
}
|
||||
/**
|
||||
* What the host asks a POI category provider for: the places of ONE of your declared
|
||||
|
||||
Reference in New Issue
Block a user