[Visual changes]
This should result in 9 visual regression failures relating to
increased height of search results and loading bar
[More details about change]
- Migrate search app from Vue 2 to Vue 3; update tests
accordingly
- Remove dependence on WVUI and use Codex instead, via the special
`@wikimedia/codex-search` package
- Update search app to use CdxTypeaheadSearch, which no longer
takes in props related to the search client or fetch start/end
instrumentation. Instead, directly use the restSearchClient
and call fetch start/end events in the search app.
- Handle hideDirection in the search app/API response formatting
code, not within the TypeaheadSearch component
- Handle showing/hiding the search button in the app
- Move the WVUI URL generator into Vector
- Update server-rendered search box styles to match design updates
included with CdxTypeaheadSearch
- Replace references to WVUI with references to Codex
- Update values of various LESS variables to match Codex, and update
searchBox styling to prevent jankiness when the searchBox is replaced
with the Codex TypeaheadSearch component
The VectorWvuiSearchOptions config variable has been maintained and
will be updated to a code-agnostic name in a future patch.
Bug: T300573
Bug: T302137
Bug: T303558
Bug: T309722
Bug: T310525
Co-Authored-By: Anne Tomasevich <atomasevich@wikimedia.org>
Change-Id: I59fa3a006d988b14ebd8020cbd58e8d7bedbfe01
Rather than test for fetch, limit the code to ES6 browsers.
Depends-On: I96a03796628a74ace93579d45a582711400c09c1
Change-Id: I4ca10182491118e61e155f99c713d4cb1b4fc7f0
In preparation for I30c670e3f195f77a27715c6b494a3088b7a55712, refactor
the search component expand behavior so that it can accomodate the new
changes in WVUI while maintaining backwards compatibility with the
status quo.
Additionally, pass/enable the `auto-expand-width` prop to the main
header's search. This will be inert until the new changes in WVUI have
landed.
Bug: T297531
Change-Id: Id8d3bd4aa74113b91ecaf66cb58cf5625db8a302
Follow up to 5dee570cb2.
It seems the mount works slightly different in that it creates a div,
appends by the App element to the element you give it, after
clearing all it's child nodes.
The previous behaviour was that the old element was /replaced/
by the App element.
Bug: T296889
Change-Id: Iee7493c032f4de5389207bba288a1a70e4cd14f3
Port the initialization code for the Vue search to use Vue.createMwApp()
instead of new Vue( ... ). The former mimicks Vue 3's API for mounting
components.
Without this change, this code breaks in Vue 3 (even in compatibility
mode) because the compat support for new Vue(...) is imperfect. By the
time renderFn is called, the searchForm container has already been
emptied by Vue's internal mounting code.
Instead, inspect searchForm and generate the prop list before mounting,
then pass the props to createMwApp() and mount the component.
Bug: T294476
Depends-On: I1fcdcf7bf87f5af2deb9763a231f2c360ea45b23
Change-Id: I5b6e66051d97e75f8f03b8258894daba22525797
Styling should not depend on IDs to allow us to have multiple
searches in the page.
Precursor for wiring up search in the sticky header.
This also tweaks performance metrics to track separate metrics
for the sticky header search
Change-Id: I5b4192a8f5a9f95af26c1faf904f7cc994323518
Per T289724#7342741, server renders an anchor tag pointing to #p-search
into the "button-start" bucket of the sticky header.
In the future after T289718, this anchor will then acts as a button when
the search module is loaded and searchToggle executes.
* skins.vector.search was modified to accomodate instantiating multiple
search components (one in the main header and one in the sticky
header).
* searchToggle.js was modified to accept a searchToggle element as a
param which the caller can then instantiate when ideal. For the sticky
header toggle, this needs to happen *after* the search module loads.
Before then, the toggle will act as a link.
* Drops one jQuery usage from searchToggle so that it can be jQuery
free. Because the native .closest method is used, IE11 support is also
dropped. However, the script feature detects and returns early if the
API isn't available.
* Makes App.vue accept an `id` prop so that multiple instances of it can
be created.
Bug: T289724
Change-Id: I1c5e6eee75918a0d06562d07c31fdcbd5a4ed6d5
The #p-search element is present in at least the Vector, Vector V2,
Timeless, and Monobook skins. This is because the HTML for the element
is generated in MediaWiki Core. At the very least, the
SearchSatisfaction instrument relies on the element always being
present.
Update the skins.vector.search module to simplify the App component
template so that it doesn't render a div#p-search element and mount that
component on the #searchform element instead.
Bug: T274869
Change-Id: Ifde679b62484fda7661fded2d978b78adac9f5da
Add event listeners and associated helpers to emit SearchSatisfaction
events via the `mediawiki.searchSuggest` protocol.
Bug: T257698
Change-Id: Ica040cd18d6c4bf8a1b1f607bb4647c7e8eb7108
Uses ResourceLoader's virtual config feature to get the config and pass
it down to Wvui's typeahead search component.
Disclaimer: I'm a typescript noob and am not sure if the
config.json.d.ts is correct although it seems to make tsc happy.
Bug: T260167
Change-Id: I2eced14c7df3b795b4de0e5149c2ca9fd598c7be
Creates a new skins.vector.search module that
replaces the searchSuggest module from MediaWiki core.
This module creates a new Vue app using the WVUI
search widget for the new search experience.
The legacy search input form is still retains on pageload,
and the new search kicks on search input focus.
In order to manage that transition, the legacy search
input is styled to resemble the new WVUI input, and the
new input is manually focused after the component mounts.
Vue is also added as a dev-dependency to help with
type-checking.
Other changes:
* the entry in skin.json is reordered alphabetically after
skins.vector.js
Bug: T264355
Change-Id: Ibb9561a77a14734297cb4d0ddcd415fc0750b45d
Roan Kattouw
Jon Robson
Nicholas Ray
Sam Smith
Jan Drewniak