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.
- Are the client responses DWIM compatible? If not, should we modify the gadget? If so, do we need a gadget API? Would it be simpler to build the transliteration into the client and just issue a second request? It's a 100 lines.
- 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)
- "Search pages containing ..." URL
- Search by title for typeahead
- Compare to the Action API and Portals implementation.
- DWIM works or a task or spike for how to support it is made.
- Search implementation is compatible with WVUI browser targets.