Follow up to 87dd101a
* bump coverage to reflect improved test state
* remove ts-ignore statements
* Drop eslint-disable-next-line compat/compat rules in ES6 code
* Drop TypeScript checking on Jest files
* Identifies an existing usage of ES7 includes method in place
where ES6 browsers need to be supported.
* Update App.vue booleans to default to false. Note this doesn't
impact our usage of the search app as we always pass these values
in.
* Drop unused eslintEs6.json configuration file
Change-Id: Ib6f1ef77bf4e27ecdcc54b5fb963818437f8195c
* Upgrade @wikimedia/types-wikimedia to allow us to drop several
@ts-ignores
* Merges eslint rules now that ES6 is default everywhere
* Runs autofix command
* Fixes various prefer-const errors
Change-Id: Iee5bcb93f10a76d80dbeec813f6387c13438263e
As far as I can tell, this has been dead code ever since it was
introduced in change Ica040cd18d (commit aa10668e6d), and was never
called; the effective search URL was initially constructed via inputs to
the search form (e.g. a hidden input for wprov), and later the separate
urlGenerator.js was added. (Also, “suggestion” is not a valid
Special:Search paramater as far as I can tell.)
Also add some tests for the separate urlGenerator.js, to make up for the
other tests being removed.
This reduces the module size of skins.vector.search enough that we can
decrease the bundle size test config to 3.2 kB [KiB].
Change-Id: I6be5ba362402c2c2ec582d9a0192c80f46e7a7ce
If the wgVectorSearchClient supports it (the default implementation
doesn’t), add a visible-item-limit to the cdx-typeahead-search, and wire
up the resulting load-more event (new in Codex v0.3) to load additional
search results on scroll.
The hard-coded visibleItemLimit (7) is chosen to match the default limit
of the wbsearchentities API, but ultimately arbitrary; we can look into
how to make this number configurable later, if necessary.
This increases the module size enough that we need to bump the bundle
size a bit more.
Bug: T322333
Change-Id: Iadade9cbf48457cfeabc78439624602ec3f98782
Co-Authored-By: Jon Robson <jdlrobson@gmail.com>
Needed-By: I67fac3b209d6a1ab2661e1e1c0681edd8472ac6c
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
