This section defines the desired state of the GitLab frontend and how we see it over the next few years. It is a living document and will adapt as technologies and team dynamics evolve.
Technologies Vue@latestKeeping up with the latest version of Vue ensures that the GitLab frontend leverages the most efficient, secure, and feature-rich framework capabilities. The latest Vue (3) offers improved performance and a more intuitive API, which collectively enhance the developer experience and application performance.
Current Status
Responsible Team
Milestones and Timelines
Challenges and Dependencies
Success Metrics
When global state management is needed, it should happen in Apollo instead of Vuex or other state management libraries. See Migrating from Vuex for more details regarding why and how we plan on migrating.
Current Status
Responsible Team
Milestones and Timelines
Challenges and Dependencies
Success Metrics
We’ll continue using HAML over Vue when appropriate. See when to add Vue application on how to decide when Vue should be chosen.
Current Status
Responsible Team
Milestones and Timelines
Challenges and Dependencies
Success Metrics
In 2019 we committed to no longer use jQuery, however we have not prioritized full removal. Our goal here is to no longer have any references to it in the primary GitLab codebase.
Current Status
Responsible Team
Milestones and Timelines
Challenges and Dependencies
Success Metrics
Similar to keeping on the latest major version of Vue, we should try to keep as close as possible to the latest version of our dependencies, unless not upgrading outweighs the benefits of upgrading. At a minimum, we will audit the dependencies annually to evaluate whether or not they should be upgraded.
Current Status
Responsible Team
Milestones and Timelines
Challenges and Dependencies
Success Metrics
Currently, GitLab mostly follows Rails architecture and Rails routing which means every single time we’re changing route, we have page reload. This results in long loading times because we are:
Ideally, we should reduce the number of times user needs to go through this long process. This would be possible with converting GitLab into a single-page application but this would require significant refactoring and is not an achievable short/mid-term goal.
The realistic goal is to move to multiple SPAs experience where we define the clusters of pages that form the user flow, and move this cluster from Rails routing to a single-page application with client-side routing. This way, we can load all the relevant context from HAML only once, and fetch all the additional data from the API depending on the route. An example of a cluster could be the following pages:
All of them have the same context (project path, current user etc.), we could easily fetch more data with issue-specific parameter (issue iid) and store the results on the client (so that opening the same issue won’t require more API calls). This leads to a smooth user experience for navigating through issues.
For navigation between clusters, we can still rely on Rails routing. These cases should be relatively more scarce than navigation within clusters.
Current Status
Responsible Team
Milestones and Timelines
Challenges and Dependencies
Success Metrics
Currently, we keep generically reusable components in two main places:
vue_shared folderWhile GitLab UI is well-documented and components are abstract enough to be reused anywhere in Vue applications, our vue_shared components are somewhat chaotic, often can be used only in certain context (for example, they can be bound to an existing Vuex store) and have duplicates (we have multiple components for notes).
We should perform an audit of vue_shared, find out what can and what cannot be moved to GitLab UI, and refactor existing components to remove duplicates and increase reusability. The ideal outcome would be having application-specific components moved to application folders, and keep reusable “smart” components in the shared folder/library, ensuring that every single piece of reusable functionality has only one implementation.
This is currently under development. Follow the GitLab Modular Monolith for FE for updates on how we will enforce encapsulation on top-level folders like vue_shared.
Current Status
Responsible Team
Milestones and Timelines
Challenges and Dependencies
Success Metrics
SASS compilation takes almost half of the total frontend compilation time. This makes our pipelines run longer than they should. Migrating to PostCSS should significantly improve compilation times.
Current Status
Responsible Team
Milestones and Timelines
Challenges and Dependencies
Success Metrics
We’re early in the process of adding visual testing, but we should have a framework established. Once implementation is determined, we’ll update this doc to include the specifics.
Current Status
Responsible Team
Milestones and Timelines
Challenges and Dependencies
Success Metrics
In 2023 we determined the tooling for accessibility testing. We opted for axe-core gem used in feature tests, to test the whole views rather then components in isolation. See documentation on Automated accessibility testing to learn when and how to include it. You can check out our progress with Accessibility scanner that uses Semgrep to find out if tests are present.
Current Status
Responsible Team
Milestones and Timelines
Challenges and Dependencies
Success Metrics
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4