Global Search - Convert UI from HAML -> Vue
What/Why
Moving forward with the later iterations of the Geo Search UX Refresh we will be adding a multitude of search filters and facets.
With the current Search Frontend Architecture we will be required to initiate a new page load for every filter. This can result in a less than desirable user experience. Especially when users are attempting to add many filters.
The page reload interaction can be seen already causing a bit of an odd affect with our most recent contribution of adding State Filters to the Issue/MR pages.
With the introduction of using a VueJS approach we can instead allow for asynchronous interactions with our server via API requests. This will also allow us to introduce both a loading screen as well as the ability to allow users to continue to "add" filters as the requests are loading. This will provide the user with a UI that is much more responsive to their interactions. This will also speed up their ability to fine tune their searches.
Current and Proposed Architecture
Current (HAML/Rails) | Proposed (Vue/HAML/Rails) | |
---|---|---|
Search Frontend Architecture | ![]() |
![]() |
Is this a priority?
At first glance this might seem like it is a "nice to have" enhancement that we can put off until we get more of the redesign efforts done. However, I would like to add some caution to this because there are some significant scalability concerns with the current code in Global Search.
The main concern here is that each "scope" in search is hardcoded into its own file. Our current approach to the UX refresh is to focus Issues and Merge Requests. With these scopes being in their own explicit files it is effectively causing double the work to enhance both of these views. This is then stretched out even further when we begin to focus on the other scopes or add new scopes (like epics). Also naturally as we focus on particular scope, the other scopes UI begins to look very dated in comparison.
Furthermore, as we continue to refresh the designs, if we ever want to change a particular thing, this then will require us to go and update that said thing in every scope's particular file.
Proposal
I would like to propose that we try and push to get the existing code moved into Vue sooner rather than later. This will provide us with the functional requirements that we need for the proposed new architecture. As well as it will allow us to introduce a more generalize solution that can handle the results view across all scopes in one generic collection of components rather than spread across many explicit files.
Discussion Update (September, 29th 2020)
After talking with @mbergeron we have found a more iterative approach to working towards this eventual goal. For context originally I had proposed we take on the Vue UI in a separate Feature Flag Block View (!42743 (closed)). This would allow us to fledge out the UI in Vue and then do a clean swap between the old and new. However, after listening to Micael's concerns we recognized that this was actually a more risky approach as we need to support both UIs for a time as well as we do not get immediate feedback on any potential issues with the new UI this way.
The New Proposed Approach
The new approach will involve replacing small components with Vue counterparts individually. These components will be injected into the existing HAML and will be able to work along with the current Rails approach. This will allow for multiple contributors to focus individual components in the Search UI without overlap.
Before we start hammering out different components we will want to create a singular Vue instance at the top level of the Search UI. Using this instance we will then bootstrap the different components we create to the single instance rather than managing individual Vue instances like we currently are in the State Filter and Confidentiality Filter.
The biggest advantage of starting with a Singular Vue instance is we can also leverage a Mixin that populates the Vuex store and that store will be shared amongst the different components (since they are all tied to the same instance). This is effectively the same way Vue typically works in situations where we are just injecting a single entry point for a full Vue application (our end goal).
As we create the different components and inject them into the HAML we will then be able to see immediate feedback from users as well as solving for issues like: #247895 (comment 414393867)
We also will be able to utilize Pajamas/GitLab UI to further speed up our development life cycle.
Finally, when we are ready to switch to a AJAX/Async approach we simply will need to implement the API calls and re-organize the files and boom we will have a fully fledged out Vue UI