40 lines
1.8 KiB
Plaintext
40 lines
1.8 KiB
Plaintext
can we implement Full-text search across pages ?
|
|
|
|
Yes, totally doable. Here's the honest breakdown:
|
|
|
|
What the Docmost API offers
|
|
|
|
Looking at the sidebar-pages endpoint pattern, Docmost likely has a
|
|
search endpoint — probably something like POST /search with a {
|
|
query: string, spaceId?: string } body. This would be the right
|
|
approach rather than fetching all pages and filtering client-side.
|
|
|
|
TUI implementation
|
|
|
|
A search screen would work like this:
|
|
|
|
┌─ Search ─────────────────────────────────┐
|
|
│ query▌ │ ← type to search
|
|
├──────────────────────────────────────────┤
|
|
│ ▶ Result page title Space name │
|
|
│ Another matching page Other space │
|
|
│ ... │
|
|
└──────────────────────────────────────────┘
|
|
Enter: open · Esc: back
|
|
|
|
- Trigger it with / or Ctrl+F from the main view
|
|
- Each keypress fires a debounced API call (e.g. wait 300ms after
|
|
last keystroke)
|
|
- Results show page title + space name
|
|
- Enter opens the selected result in the editor
|
|
- Esc goes back
|
|
|
|
The debounce part is the only tricky bit in the async loop — you'd
|
|
track a last_typed: Instant and only fire the search if elapsed() >
|
|
300ms without new input.
|
|
|
|
Caveat: if Docmost's API doesn't expose a search endpoint, you'd
|
|
have to fetch all pages across all spaces and do client-side string
|
|
matching, which is slow and not full-text. Worth checking the API
|
|
docs first to confirm the endpoint exists before building it.
|