Change Details

T260065 provided an initial integration of WVUI into Vector with the component available at the time, wvui-input. The complete search component is nearing completion in T256041 and must be reintegrated. The final mocks show a complete search form, not just an input and dropdown. This integration faces many of the same challenges identified in T260065: - The server-rendered HTML is generated with PHP, not Vue.js. Client hydration is very delicate and expects an exact version of the client HTML to be provided in the server-side render. - The styling of the component before (SSR) and after client hydration (JavaScript) must be correct. - The searchSatisfaction client instrumentation loads on every pageview and [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/WikimediaEvents/+/17ccf21/modules/ext.wikimediaEvents/searchSatisfaction.js#662 | alters the DOM ]] whenever the form is submitted. - Per T249306, the search experience does not load until the user focus on the search form which means the user is likely to be actively typing their query when dependency loading completes. In other words, focus state, selection state, and input value must be preserved. If the DOM changes, the CSS transition styles cause the focus to flicker. - Per T254695, we want the transition to be seamless and perceived as prompt. - Other JavaScript, such as [[ https://www.mediawiki.org/wiki/Help:Extension:UniversalLanguageSelector/Input_methods | UniversalLanguageSelector's Input Methods ]] (also called "input tools") load by default on some wiki (on user input focus!) and bind to the inputs. Another example is the [[ https://he.wikipedia.org/wiki/%D7%9E%D7%93%D7%99%D7%94_%D7%95%D7%99%D7%A7%D7%99:Gadget-Dwim.js | DWIM gadget ]] which is a default on hewiki. - Input value and focus states must be persisted on hydration. - Search input //and// results are Vue.js powered. The input has a submit button and the results are generated on the fly. The structure of the input itself differs from Vector's SSR and requires multiple elements. The implementation provided in T256041 can be modified as wanted but the expected that the final implementation in Vector will at least directly include either the whole search form, wvui-search-form (the input, dropdown, button and hidden form elements in a single component), or a composition of the pieces wanted including wvui-typeahead-search (the input and dropdown in a single component) and wvui-button depending on any difficulties encountered in integration. ## Acceptance criteria [] The server rendered HTML is updated to the new client HTML. This will likely require splitting the Legacy and Latest Mustache templates. This is probably a good distinct patch to write if the approach makes sense. [] The needed WVUI client styles for the search form are made available for the server rendered experience. These styles are currently bundled into skins.vector.search.css but skin.json needs to be revised to actually include them on SSR. All WVUI styles should be well isolated by classname so there shouldn't be a conflict. [] Legacy mode only needs to support Legacy search but Latest mode must support Legacy and Latest (Vue.js) search so as to allow for rollback as needed. [] searchSatisfaction client instrumentation doesn't explode.

T260065 provided an initial integration of WVUI into Vector with the component available at the time, wvui-input. The complete search component is nearing completion in T256041 and must be reintegrated. The final mocks show a complete search form, not just an input and dropdown. This integration faces many of the same challenges identified in T260065: - The server-rendered HTML is generated with PHP, not Vue.js. Client hydration is very delicate and expects an exact version of the client HTML to be provided in the server-side render. - The styling of the component before (SSR) and after client hydration (JavaScript) must be correct. - The searchSatisfaction client instrumentation loads on every pageview and [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/WikimediaEvents/+/17ccf21/modules/ext.wikimediaEvents/searchSatisfaction.js#662 | alters the DOM ]] whenever the form is submitted. - Per T249306, the search experience does not load until the user focus on the search form which means the user is likely to be actively typing their query when dependency loading completes. In other words, focus state, selection state, and input value must be preserved. If the DOM changes, the CSS transition styles cause the focus to flicker. - Per T254695, we want the transition to be seamless and perceived as prompt. - Other JavaScript, such as [[ https://www.mediawiki.org/wiki/Help:Extension:UniversalLanguageSelector/Input_methods | UniversalLanguageSelector's Input Methods ]] (also called "input tools") load by default on some wiki (on user input focus!) and bind to the inputs. Another example is the [[ https://he.wikipedia.org/wiki/%D7%9E%D7%93%D7%99%D7%94_%D7%95%D7%99%D7%A7%D7%99:Gadget-Dwim.js | DWIM gadget ]] which is a default on hewiki. - Input value and focus states must be persisted on hydration. - Search input //and// results are Vue.js powered. The input has a submit button and the results are generated on the fly. The structure of the input itself differs from Vector's SSR and requires multiple elements. The implementation provided in T256041 can be modified as wanted but the expected that the final implementation in Vector will at least directly include either the whole search form, wvui-search-form (the input, dropdown, button and hidden form elements in a single component), or a composition of the pieces wanted including wvui-typeahead-search (the input and dropdown in a single component) and wvui-button depending on any difficulties encountered in integration. ## Acceptance criteria [] The server rendered HTML is updated to the new client HTML. This will likely require splitting the Legacy and Latest Mustache templates. This is probably a good distinct patch to write if the approach makes sense. [] The needed WVUI client styles for the search form are made available for the server rendered experience. These styles are currently bundled into skins.vector.search.css but skin.json needs to be revised to actually include them on SSR. All WVUI styles should be well isolated by classname so there shouldn't be a conflict. This is probably another distinct patch if the approach makes sense. [] Legacy mode only needs to support Legacy search but Latest mode must support Legacy and Latest (Vue.js) search so as to allow for rollback as needed. [] searchSatisfaction client instrumentation doesn't explode.

T260065 provided an initial integration of WVUI into Vector with the component available at the time, wvui-input. The complete search component is nearing completion in T256041 and must be reintegrated. The final mocks show a complete search form, not just an input and dropdown. This integration faces many of the same challenges identified in T260065: - The server-rendered HTML is generated with PHP, not Vue.js. Client hydration is very delicate and expects an exact version of the client HTML to be provided in the server-side render. - The styling of the component before (SSR) and after client hydration (JavaScript) must be correct. - The searchSatisfaction client instrumentation loads on every pageview and [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/WikimediaEvents/+/17ccf21/modules/ext.wikimediaEvents/searchSatisfaction.js#662 | alters the DOM ]] whenever the form is submitted. - Per T249306, the search experience does not load until the user focus on the search form which means the user is likely to be actively typing their query when dependency loading completes. In other words, focus state, selection state, and input value must be preserved. If the DOM changes, the CSS transition styles cause the focus to flicker. - Per T254695, we want the transition to be seamless and perceived as prompt. - Other JavaScript, such as [[ https://www.mediawiki.org/wiki/Help:Extension:UniversalLanguageSelector/Input_methods | UniversalLanguageSelector's Input Methods ]] (also called "input tools") load by default on some wiki (on user input focus!) and bind to the inputs. Another example is the [[ https://he.wikipedia.org/wiki/%D7%9E%D7%93%D7%99%D7%94_%D7%95%D7%99%D7%A7%D7%99:Gadget-Dwim.js | DWIM gadget ]] which is a default on hewiki. - Input value and focus states must be persisted on hydration. - Search input //and// results are Vue.js powered. The input has a submit button and the results are generated on the fly. The structure of the input itself differs from Vector's SSR and requires multiple elements. The implementation provided in T256041 can be modified as wanted but the expected that the final implementation in Vector will at least directly include either the whole search form, wvui-search-form (the input, dropdown, button and hidden form elements in a single component), or a composition of the pieces wanted including wvui-typeahead-search (the input and dropdown in a single component) and wvui-button depending on any difficulties encountered in integration. ## Acceptance criteria [] The server rendered HTML is updated to the new client HTML. This will likely require splitting the Legacy and Latest Mustache templates. This is probably a good distinct patch to write if the approach makes sense. [] The needed WVUI client styles for the search form are made available for the server rendered experience. These styles are currently bundled into skins.vector.search.css but skin.json needs to be revised to actually include them on SSR. All WVUI styles should be well isolated by classname so there shouldn't be a conflict. This is probably another distinct patch if the approach makes sense. [] Legacy mode only needs to support Legacy search but Latest mode must support Legacy and Latest (Vue.js) search so as to allow for rollback as needed. [] searchSatisfaction client instrumentation doesn't explode.