Description
A user should be able to search for addresses for any waypoint instead of only being able to select waypoints by clicking in the map.
The addressSearch plugin provides the search machinery (a search action, reactive searchResults, selectResult; see store.ts). However, in its current implementation addressSearch is not designed to present its results anywhere other than in its own UI:
- It is a single-instance store with a single shared
inputValue, searchResults and chosenAddress. It cannot hold independent search state for multiple waypoints in parallel.
- Results are rendered exclusively by
SearchResults.ce.vue.
- The default
selectResult writes the chosen feature back into addressSearch's own state (chosenAddress, inputValue), not into a possibly consuming plugin.
Making search results appear within the routing plugin therefore requires decoupling the search state and result presentation from the addressSearch UI, not just calling existing actions.
A prior Vue 2 attempt exists as a commented-out search stub in vue2/packages/plugins/Routing/src/store/actions.ts, which already flagged that "results are currently shown in @polar/plugin-address-search and not in the related input in this plugin."
Current behavior
A user can only select waypoints by clicking in the map.
- The clicked coordinate is written into the focused waypoint via
addCoordinateToRoute and the input in RoutingInput.ce.vue binds directly to route[index].
- There is no text search field or connection to
addressSearch in routing and addressSearch can only surface results in its own component.
Expected behavior
If a client has the plugins addressSearch and reverseGeocoder configured, a user is able to search for addresses directly in the routing plugin to be able select waypoints.
- Each waypoint input allows entering a search term that triggers an
addressSearch search. Results are shown in the context of the routing waypoint (not in the standalone addressSearch component) and a loading indicator while pending.
- Selecting a result sets the corresponding waypoint's coordinate in
route (derived from the feature geometry) without disturbing an independent addressSearch UI.
- Multiple waypoints can each have their own search/results state, so switching between waypoints does not clobber another waypoint's query or results.
- If
addressSearch (and reverseGeocoder) are not configured, behavior is unchanged and waypoints can still be selected by clicking in the map (feature is opt-in/graceful).
- Map-click selection continues to work alongside search.
Affected areas
| File |
What needs to change |
src/plugins/addressSearch/store.ts |
Decouple search state so results can be consumed outside the plugin. This can be accomplished by e.g. supporting a programmatic search that returns results without mutating inputValue/searchResults/chosenAddress. Abstract selectResult to a lib-function so both routing and addressSearch can deliver a feature to the respective plugin without altering the other. |
src/plugins/addressSearch/components/SearchResults.ce.vue |
Refactor into a reusable result-list component that is not hard-bound to useAddressSearchStore and does not depend on fixed addressSearch DOM IDs for focus/keyboard handling, so it can be embedded in routing. |
src/plugins/addressSearch/components/AddressSearch.ce.vue |
Adapt to the extracted result component while preserving existing standalone behavior. |
src/plugins/addressSearch/types.ts |
Extend types for programmatic/embedded usage and result delivery (e.g. selection callbacks). |
src/plugins/routing/store.ts |
Add search state/actions that delegate to addressSearch while still navigating the independence of both plugins. Map a selected result's geometry into the focused waypoint of route. |
src/plugins/routing/components/RoutingInput.ce.vue and src/plugins/routing/components/RoutingWrapper.ce.vue |
Turn the waypoint field into a search input and embed the reusable result list + loader per waypoint. If addressSearch is not configured, the current behaviour should stay untouched. |
src/plugins/routing/types.ts |
Extend RoutingPluginOptions for any needed search configuration e.g. which addressSearch group/method to use. |
Out of scope
The connection with reverseGeocoder is handled in #864.
Description
A user should be able to search for addresses for any waypoint instead of only being able to select waypoints by clicking in the map.
The
addressSearchplugin provides the search machinery (asearchaction, reactivesearchResults,selectResult; see store.ts). However, in its current implementationaddressSearchis not designed to present its results anywhere other than in its own UI:inputValue,searchResultsandchosenAddress. It cannot hold independent search state for multiple waypoints in parallel.SearchResults.ce.vue.selectResultwrites the chosen feature back intoaddressSearch's own state (chosenAddress,inputValue), not into a possibly consuming plugin.Making search results appear within the
routingplugin therefore requires decoupling the search state and result presentation from theaddressSearchUI, not just calling existing actions.A prior Vue 2 attempt exists as a commented-out search stub in
vue2/packages/plugins/Routing/src/store/actions.ts, which already flagged that "results are currently shown in@polar/plugin-address-searchand not in the related input in this plugin."Current behavior
A user can only select waypoints by clicking in the map.
addCoordinateToRouteand the input inRoutingInput.ce.vuebinds directly toroute[index].addressSearchinroutingandaddressSearchcan only surface results in its own component.Expected behavior
If a client has the plugins
addressSearchandreverseGeocoderconfigured, a user is able to search for addresses directly in theroutingplugin to be able select waypoints.addressSearchsearch. Results are shown in the context of the routing waypoint (not in the standaloneaddressSearchcomponent) and a loading indicator while pending.route(derived from the feature geometry) without disturbing an independentaddressSearchUI.addressSearch(andreverseGeocoder) are not configured, behavior is unchanged and waypoints can still be selected by clicking in the map (feature is opt-in/graceful).Affected areas
src/plugins/addressSearch/store.tsinputValue/searchResults/chosenAddress. AbstractselectResultto alib-function so bothroutingandaddressSearchcan deliver a feature to the respective plugin without altering the other.src/plugins/addressSearch/components/SearchResults.ce.vueuseAddressSearchStoreand does not depend on fixedaddressSearchDOM IDs for focus/keyboard handling, so it can be embedded inrouting.src/plugins/addressSearch/components/AddressSearch.ce.vuesrc/plugins/addressSearch/types.tssrc/plugins/routing/store.tsaddressSearchwhile still navigating the independence of both plugins. Map a selected result's geometry into the focused waypoint ofroute.src/plugins/routing/components/RoutingInput.ce.vueandsrc/plugins/routing/components/RoutingWrapper.ce.vueaddressSearchis not configured, the current behaviour should stay untouched.src/plugins/routing/types.tsRoutingPluginOptionsfor any needed search configuration e.g. whichaddressSearchgroup/method to use.Out of scope
The connection with
reverseGeocoderis handled in #864.