The legacy search wprov behavior, implemented in the WikimediaEvents
extension in searchSatisfaction.js, is to use acrw1_ as the prefix (i.e.
with an underscore before the index), and acrw1_-1 for user searches
that didn’t select a suggestion (not acrw1). Make the Vue search match
this in both cases.
Bug: T317682
Change-Id: I6c84533e1811233ff2727d501327471d73fc7b62
This ensures that the wprov parameter is included when users follow the
link as a link (click, middle-click, etc.), and also prepares us for a
future where pressing Enter after selecting a search result navigates to
that result’s URL instead of submitting the form. It also matches the
behavior of the legacy search form.
We put this in App.vue + instrumentation.js, not in urlGenerator.js,
because we also want wprov to be added when custom URL generators or
search clients are used. (The reason for instrumentation.js instead of
purely App.vue is just that it’s easier to test there.)
In the tests, we need to update @wikimedia/mw-node-qunit so that we have
a sufficiently functional mw.Uri() mock.
Bug: T317682
Change-Id: I765d3bbf89b2253add7b50305c362e4bbc9ecceb
Change I765d3bbf89 pushes the module over the configured maximum allowed
size (3 KiB, see bundlesize.config.json); shave off some bytes elsewhere
to bring it below the limit again. IMHO all of these changes should be
acceptable:
* arrow functions are already used elsewhere in this module;
* using the mw.config.get() fallback argument is normal (it slightly
changes behavior, but I don’t think explicitly setting the search
client or URL generator to a falsy value and expecting to get the
default behavior should be considered supported);
* not quoting [name="search"] matches [name=title] immediately above;
* using forEach() with a function reference is still readable (initApp()
is now called with extra arguments, but that doesn’t matter).
Change-Id: I45dda26cb59279d91804b0c2bbf12174fa78ee12
[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
Vector's tsc version is currently reporting errors that the latest
typescript version doesn't report and vice versa. Upgrade to the latest
version to avoid these discrepancies.
Additionally:
Fix tsc errors that are now reported by updated version
Bug: T297614
Change-Id: I0eb67bcc1a5ce214fcf2d6f6433a5de3a845b6a6
Eslint is throwing compat warnings on every commit in Vector. This
commit silences those warnings.
Change-Id: I0e914c6179745415e916fadd382d86baa72e3e63
This is almost identical to the instrumentation currently used in
production for mediawiki.searchSuggest -- the only differences being in
the nomenclature of variables, etc.
As part of comparing Vue search with legacy search, we need to track how
long it takes a keypress to load and render search results for Vue
search. This will only be used only in synthetic testing at this time
(Real user monitoring (RUM) is not in scope for this ticket).
To test locally, first enter characters in input. Then to see the
metrics recorded:
```
// View all marks
performance.getEntriesByType('mark');
// View all measures
performance.getEntriesByType('measure');
```
This commit adds the following metrics which will only be used in our
synthetic tests. We are not collecting RUM metrics at this time.
Measures:
* mwVectorVueSearchLoadStartToFirstRender: Measures the time it takes
from the start of loading the search module to the first render of results.
* mwVectorVueSearchQueryToRender: Measures the time it takes from
the start of the fetch to the render of search results.
Bug: T251544
Change-Id: I39200648a3a0a4079a132134d142ad8997c8962a
Add event listeners and associated helpers to emit SearchSatisfaction
events via the `mediawiki.searchSuggest` protocol.
Bug: T257698
Change-Id: Ica040cd18d6c4bf8a1b1f607bb4647c7e8eb7108
