Struct Search 

pub struct Search { /* private fields */ }

Search over a navigation surface (docs/search.md), declared with Nav::searchable: Search::new(query).prompt(res::str::search()).reveal(SearchReveal::OnPull).

Search is declared on the surface, not on the toolbar, the same move SwiftUI made with .searchable(). That is what lets the platform choose where to draw the field: the window toolbar on a wide window, attached to the navigation list on a narrow one, without the app branching on either. The query and the scope are app-owned bindings, which is what lets the field move between placements without the state moving with it. A Search holds those bindings, so build it where the nav is built; it is not a value to share across windows.

Implementations

impl Search

pub fn new(query: impl Binding<String>) -> Search

Search bound two-way to query (a Signal<String> or any other binding).

pub fn prompt<M>(self, prompt: impl IntoText<M>) -> Search

The field’s empty-state prompt.

pub fn placement(self, placement: SearchPlacement) -> Search

Ask for a particular placement. A preference: a backend that cannot honor it falls back to its platform’s own convention, so Automatic (the default) is almost always right.

pub fn reveal(self, reveal: SearchReveal) -> Search

How the field comes and goes on a phone (default SearchReveal::Always).

pub fn scopes<M>( self, scope: impl Binding<usize>, titles: impl IntoIterator<Item = impl IntoText<M>>, ) -> Search

A one-of-N scope bar under the field, bound to scope (an index into titles).

Native on UIKit alone; elsewhere it is a native component doing the same job (a Material ChipGroup of single-selection filter chips, an ArkUI SegmentButtonV2, an NSSegmentedControl) or, on web and system XAML, one composed from primitives.

pub fn suggestions(self, f: impl Fn(&str) -> Vec<String> + 'static) -> Search

Completions for the current text, re-derived whenever a reactive read inside f changes.

On a navigation surface these complete the field rather than replacing the list: the list is already the filtered result set, so an overlay of results would cover the very thing it is narrowing. Backends whose search widget does completions natively use it (AutoSuggestBox, QCompleter, <datalist>, UISearchResultsUpdating).

pub fn on_submit(self, f: impl Fn(&str) + 'static) -> Search

Run f with the field’s text when the user presses its Return or Search key: the trigger for a search that runs on demand (a server query) instead of narrowing as the text changes. query already holds the text when f runs.

pub fn available<M>(self, v: impl IntoReactive<bool, M>) -> Search

Offer a page’s field only while v is true (default: always), for a page that learns whether it can be searched after it shows: a feed that has to load first. The field keeps its text while it is withdrawn. A navigation surface’s search ignores this.