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
