Page MenuHomePhabricator

wikibase.entityselector.search hook does not handle pagination
Open, Needs TriagePublic

Description

The wikibase.entityselector.search hook does not handle pagination at all, which makes it difficult to use for improving search results.

The hook is only fired after the initial search, not when clicking "more", so the following only logs data once for a given search, no matter how many times you click "more":

mw.hook("wikibase.entityselector.search").add(function (data, addPromise) { console.log(data); });

Suggestions added via the promise do not get paginated, so the following shows between 20 and 27 results (the 20 results added via the promise plus the original results):

var suggestions = [
	{ id: "Q1" },{ id: "Q2" },{ id: "Q3" },{ id: "Q4" },
	{ id: "Q5" },{ id: "Q6" },{ id: "Q7" },{ id: "Q8" },
	{ id: "Q9" },{ id: "Q10" },{ id: "Q11" },{ id: "Q12" },
	{ id: "Q13" },{ id: "Q14" },{ id: "Q15" },{ id: "Q16" },
	{ id: "Q17" },{ id: "Q18" },{ id: "Q19" },{ id: "Q20" }
];
mw.hook("wikibase.entityselector.search").add(function (data, addPromise) { addPromise(suggestions); });

Suggestions added via the promise do not override results added after clicking "more", so the following does not override "River (given name)" in the second set of results when searching for "river":

mw.hook("wikibase.entityselector.search").add(function (data, addPromise) { addPromise([{ id: "Q66103377", label: "custom result" }]); });

Event Timeline

@Michael @ItamarWMDE Could one of you have a brief look to see if this is actually the case or if there is maybe some issue in nikki's code?

I'll have a quick look.

which makes it difficult to use for improving search results.

Could you briefly outline what improvements you have in mind for these search results? I think that would be useful to know for future iterations on the search (both in terms of UI and in terms of backend functionality)

This is actually the case and apparently this is intentional?


			if ( this._cache.term === term ) {
				return hookResults; // Don't fire hook when paginating
			}

from https://github.com/wikimedia/Wikibase/blob/6ac4b05a5f804acb1c3452cdfe0306c1ac2027a1/view/resources/jquery/wikibase/jquery.wikibase.entityselector.js#L348-L350

This code was added in Introduce entity suggestions hook (I88ab3709) for T199672. Though in neither I can find a discussion for why the hook is not supposed to fire for pagination.

Could you briefly outline what improvements you have in mind for these search results? I think that would be useful to know for future iterations on the search (both in terms of UI and in terms of backend functionality)

I'd like to add descriptions when they're missing, by setting the description to the P31 value (T141553, T159106, T303677). I was able to do it for the first 7 results, but not for the results after the first page.

For lexemes, I'd like to add P5185 (grammatical gender), P5911 (paradigm class) and P5923 (creates lexeme type) when they're defined to help distinguish some of the lexemes which currently can't be distinguished other than by ID (T274899).

I also have a user script which provides various search results and entity suggestions for lexemes, since lexemes don't have an entity suggester (T201590) and there's no way to search for senses (T271500). For those, my results are the only results, and I don't seem to be able to tell it to paginate the results.

A number of properties for lexemes are designed to be used between lexemes for the same language (e.g. P5401 (auxiliary verb), P5973 (synonym)), and I'd like to prioritise (or ideally only show) lexemes in the same language.

This code was added in Introduce entity suggestions hook (I88ab3709) for T199672. Though in neither I can find a discussion for why the hook is not supposed to fire for pagination.

Probably because we mainly added the hook to provide suggestions based on constraints – we made it part of the stable interface and available for other uses as well, but constraint suggestions were the main thing we had in mind, and I guess pagination didn’t seem necessary there. I feel like the code you found might just be a simple way to stop the same suggestions from being added a second time when the user scrolled (instead of… deduplicating results in the search handler, I guess).