Change Details

As part of {T274903} we made sure an exact match is always shown at the very top of the dropdown when searching for a template name. This is critical for templates like [Template:!!](https://en.wikipedia.org/wiki/Template:!!). As of https://gerrit.wikimedia.org/r/693157 the code does an additional API request to achieve this. The main disadvantage of this approach is a lower response time which can be noticeable while typing a template name. Suggestion: * Do the additional API request asynchronously. This means the dropdown will show up faster, but with the exact match at the top possibly missing. * The exact match will be inserted a few milliseconds later, when the additional API request is done. An implementation as naive as this means all items in the dropdown will shift down. This will be more and more confusing the higher the response time is. To avoid this shift, we can add a placeholder item at the top as long as we don't know if an exact match exists or not. This placeholder item is either gray and can not be selected. Or it is shown as a "red link" that can be selected. This will work exactly the same as in wikitext where it is very much possible to start "using" a template even before it exists. Open questions: * Do users understand the interaction with a disabled/red item? (#wmde-design?) * When the only (?) benefit is a faster response time, is the effort worth it? * Maybe it's possible to achieve the same (or even better) performance gain by combining the other 2 API requests (search + templatedata) that already exist? Compare with #mediawiki-extensions-templatewizard where this is already done.

As part of {T274903} we made sure an exact match is always shown at the very top of the dropdown when searching for a template name. This is critical for templates like [Template:!!](https://en.wikipedia.org/wiki/Template:!!). As of https://gerrit.wikimedia.org/r/693157 the code does an additional API request to achieve this. The main disadvantage of this approach is a lower response time which can be noticeable while typing a template name. Suggestion: * Run the two API requests in parallel (using promises) and continue when both are finished. * Note: The exact match request may be useless in case the other request already contains the exact match. This should be fine. It might waste a bit of bandwidth, but usually doesn't waste time – at least not when we assume that the exact match request is always faster. It might also be possible to quit the exact match earlier when it turns out it's not needed. Open question: * Maybe it's possible to achieve the same (or even better) performance gain by combining the other 2 API requests (search + templatedata) that already exist? Compare with #mediawiki-extensions-templatewizard where this is already done.

As part of {T274903} we made sure an exact match is always shown at the very top of the dropdown when searching for a template name. This is critical for templates like [Template:!!](https://en.wikipedia.org/wiki/Template:!!). As of https://gerrit.wikimedia.org/r/693157 the code does an additional API request to achieve this. The main disadvantage of this approach is a lower response time which can be noticeable while typing a template name. Suggestion: * Do the additional API request asynchronously. This means the dropdown will show up faster, but with the exact match at the top possibly missingRun the two API requests in parallel (using promises) and continue when both are finished. * The exact match will be inserted a few milliseconds later,Note: The exact match request may be useless in case the other request already contains the exact match. This should be fine. It might waste a bit of bandwidth, but usually doesn't waste time – at least not when we assume that the exact match request is always faster. whenIt might also be possible to quit the additional API request is doneexact match earlier when it turns out it's not needed. An implementation as naive as this means all items in the dropdown will shift down. This will be more and more confusing the higher the response time is. To avoid this shift, we can add a placeholder item at the top as long as we don't know if an exact match exists or not. This placeholder item is either gray and can not be selected. Or it is shown as a "red link" that can be selected. This will work exactly the same as in wikitext where it is very much possible to start "using" a template even before it exists. Open questions: * Do users understand the interaction with a disabled/red item? (#wmde-design?) * When the only (?) benefit is a faster response time, is the effort worth it?Open question: * Maybe it's possible to achieve the same (or even better) performance gain by combining the other 2 API requests (search + templatedata) that already exist? Compare with #mediawiki-extensions-templatewizard where this is already done.