One question at the heart of this implementation is what can rely purely on core and what is dependent on other extensions.

The following is based on a conversation with @matthiasmullie

---

Options include:

• fetching all data from some API (individually, per result that’s clicked),
• feed it from PHP to JS like we do with MediaSearch (via js vars, or included in some nodes/attributes hidden from the user, but then we’ll need to include that data for all results at once, and we should not include large blobs of data because that would quickly result in an absurdly large html payload)
• Or some hybrid approach.

Broadly quickview will consist of:

1. information already in the search result (e.g. thumbnail, title)
2. the opening text of an article, or a larger relevant snippet (still TBD whether that’s possible, AFAIK)
3. list of the article’s sections
4. results from other projects (e.g. commons)

APIs

Thumbnails

2 props (&prop=images & &prop=pageimages) that could be useful - especially that last one, that seems to pick just 1 thumbnail & allows requesting it in whatever size we want. Combined with the search generator, we’d get something like this: https://en.wikipedia.org/w/api.php?action=query&generator=search&gsrsearch=cat&prop=pageimages. That’s search + thumbnails in 1 api call.

Sadly, that API seems to live in extensions/PageImages/includes/ApiQueryPageImages.php.

Results

We'll already have those and can be passed via a js var.

(that other one, &prop=images, does live in core; but it seems to be missing images for a lot of pages anyway, so probably not very useful)

Snippets

in the case of a relevant snippet, we’re going to need to get that straight from search, so that’ll probably either end up coming from core or cirrussearch.

in the case of “just a snippet of text”, we can probably use either the page summary rest API (also used by Page Previews; not part of core), or prop=extracts (via Extension:TextExtracts), or use the parse API (in core) to get the full HTML and just snip out some opening text up to however many characters we want; or use the opening_text already indexed by search (that extraction is in core AFAIK) and add a new API to surface that

The ideal scenario here may be to fetch it from non-core sources, but we may be able to fall back to core. Ccould imagine us using some hooking mechanism to provide the data, and fall back to something provided by core if nothing is available (or simply don’t show a snippet, but then we’ll get to the question “if we can’t get enough relevant data from core, should quickview itself even be in core).

Article sections

Sections is easy: action=parse&prop=sections; e.g. https://en.wikipedia.org/w/api.php?action=parse&page=Cat&prop=sections. This lives in core

Sister projects

Can imagine this being something that could fit right in with core (e.g. seen some mocks that show relevant images - they could be from commons or own wiki depending on config), or something that simply doesn’t fit (e.g. requires captions for which we’d need wikibase/mediainfo)

Interwiki links based stuff - nowadays this data is powered by wikibase, but they’ve made this very much compatible with the old interwiki links core in core. The parse API (in core) certainly exposes these with action=parse&prop=iwlinks; e.g. https://en.wikipedia.org/w/api.php?action=parse&page=Seal_(musician)&prop=iwlinks. The query API does so too, with action=query&prop=iwlinks (ApiQueryIWLinks.php in core); e.g. https://en.wikipedia.org/w/api.php?action=query&prop=iwlinks&titles=Seal_(musician)

Implementaion

Based on conversations with Design Systems ( @Catrope and @AnneT )

One thing that could be considered is to implement the basic UI stuff in core, and have the extension or an API provide the data for it. That's what is being done for Wikidata in the article search bar: it can be fed thumbnails, description text and language tags for that text based on what whats provided from either the regular API or the Wikidata one, and the "core" search component knows how to display that.

In this task that might look like rendering additional text/links/list items as provided by an extension

If that doesn't work, another thing we could consider is allowing the extension to supply arbitrary HTML, and just dumping it into the component with <div v-html="stuffFromTheExtension" />. That's uglier but more versatile.

If we need the extension stuff to be interactive, and basically be its own Vue component, then we're in unchartered territory. In that case the extension could provide a Vue component which the core search UI could embed with <component :is="extensionComponent" /> where extensionComponent is a component object (an object that has name, data, computed, etc properties, AKA the result of require( './Foo.vue' ))

We should try to avoid crossing the streams too much and keep things somewhat generic. We shouldn't have core code directly check whether a specific extension is enabled, but it would be OK to have a config setting or hook that the extension hooks into to active certain behavior. Or to have a hook that basically asks "is anyone interested in adding content here/ providing the implementation for a certain behavior?", and if no extension responds to that hook call, skipping certain parts of the core code.

Maintainability

Quickview could an extension (existing one, or even totally new) - it’s mostly “just an enhancement”, searching would still work fine without it. The main benefit would be that it’d be simpler: we’d only need to worry about the WMF ecosystem and what extensions/data/technology are available there, and not jump through some hoops to provide decent alternatives/fallback for when that data may not be there.

Whilst the structured data team have been tasked with the short term work of improving the search experience, the long term maintenance of the search front end is not our teams responsibilities and serious considerations should be made about what the most sustainable approach to making these changes. The team is concerned that creating yet another separate extension for search would add to the problem of abandonware, and as such whilst it is an option to create a separate extension; it is broadly our teams belief it isn't in the best interests of Wikimedia for this to occur.

Having it in core is beneficial because it becomes the standard, and its reduces the possibility that other new stuff introduced could somehow conflict with this in unforseen ways. That can easily be coordinated in core, and rollout should also be easier from a technical perspective.

Stakeholders

• Design systems
• Search platform
• Performance ( see Txxxxxx )

Summary

The vue.js implementation for quickview to be primarily done in core with the caveats detailed in the implementation notes ( T307560#7926123 ) and augmented via extensions should that be absolutely necessary.