This is a skeletal task for implementing a network client for the new search Desktop Improvements Project / FAWG search experience. The interface approach taken by Popups (RESTBase / Action ) seems to have worked well and allows the underlying service to be swapped between the Action API, RESTBase, and mocked data so it should probably be considered for this task.
Questions
- Is the caching sensible? For example, if a user types "f", "o", "o", <backspace>, can the browser served cached results for "fo"?
- Do we need an A/B test for the network clients?
- What types are nullable, undefined, or missing? It's not yet documented as far as I can tell.
- What behavior do we want for submission? Portals uses //wikipedia.org/search-redirect.php, wikis use /w/index.php. The former lands on https://en.wikipedia.org/w/index.php?cirrusUserTesting=glent_m0&search=no+matching+query&title=Special%3ASearch&go=Go&ns0=1 and he latter lands on https://en.wikipedia.org/wiki/Special:Search?search=no+matching+query&go=Go&ns0=1. Matches (including redirects) go to the page on both.
Docs and examples
- Example client implementation for Action API that implements an interface (only has "by title" implementation)
- Documentation
- "Search pages containing ..." URL
- Search by title for typeahead
Acceptance criteria
- Compare to the Action API and Portals implementation.
- DWIM works or a task or spike for how to support it is made. See T262566.
- Search implementation is compatible with WVUI browser targets.