Frontend Goals

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@latest

Keeping 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

  • As of December 2023: GitLab is currently using Vue 2.x.
  • Progress: (Brief description of progress)

Responsible Team

Milestones and Timelines

  • (Key milestones, expected completions)

Challenges and Dependencies

  • (Any major challenges)

Success Metrics

State Management

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

  • As of December 2023: (Status)
  • Progress: (Brief description of progress)

Responsible Team

  • Task Group:
  • Facilitator:

Milestones and Timelines

  • (Key milestones, expected completions)

Challenges and Dependencies

  • (Any major challenges)

Success Metrics

  • (Potential metrics)

HAML by default

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

  • As of December 2023: (Status)
  • Progress: (Brief description of progress)

Responsible Team

  • Task Group:
  • Facilitator:

Milestones and Timelines

  • (Key milestones, expected completions)

Challenges and Dependencies

  • (Any major challenges)

Success Metrics

  • (Potential metrics)

Complete removal of jQuery

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

  • As of December 2023: (Status)
  • Progress: (Brief description of progress)

Responsible Team

  • Task Group:
  • Facilitator:

Milestones and Timelines

  • (Key milestones, expected completions)

Challenges and Dependencies

  • (Any major challenges)

Success Metrics

  • (Potential metrics)

Dependencies management

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

  • As of December 2023: (Status)
  • Progress: (Brief description of progress)

Responsible Team

  • Task Group:
  • Facilitator:

Milestones and Timelines

  • (Key milestones, expected completions)

Challenges and Dependencies

  • (Any major challenges)

Success Metrics

  • (Potential metrics)

Best Practices

Scalability and Performance

Cluster SPAs

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:

  • rendering HAML page;
  • mounting Vue applications if we have any;
  • fetching data for these applications

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:

  • Issues page
  • Issue boards page
  • Issue details page
  • New issue page
  • editing an issue

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

  • As of December 2023: (Status)
  • Progress: (Brief description of progress)

Responsible Team

  • Task Group:
  • Facilitator:

Milestones and Timelines

  • (Key milestones, expected completions)

Challenges and Dependencies

  • (Any major challenges)

Success Metrics

  • (Potential metrics)

Reusable components

Currently, we keep generically reusable components in two main places:

  • GitLab UI
  • vue_shared folder

While 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

  • As of December 2023: (Status)
  • Progress: (Brief description of progress)

Responsible Team

  • Task Group:
  • Facilitator:

Milestones and Timelines

  • (Key milestones, expected completions)

Challenges and Dependencies

  • (Any major challenges)

Success Metrics

  • (Potential metrics)

Migrate to PostCSS

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

  • As of December 2023: (Status)
  • Progress: (Brief description of progress)

Responsible Team

  • Task Group:
  • Facilitator:

Milestones and Timelines

  • (Key milestones, expected completions)

Challenges and Dependencies

  • (Any major challenges)

Success Metrics

  • (Potential metrics)

Collaboration and Tooling

Visual Testing

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

  • As of December 2023: (Status)
  • Progress: (Brief description of progress)

Responsible Team

  • Task Group:
  • Facilitator:

Milestones and Timelines

  • (Key milestones, expected completions)

Challenges and Dependencies

  • (Any major challenges)

Success Metrics

  • (Potential metrics)

Accessibility testing

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

  • As of December 2023: (Status)
  • Progress: (Brief description of progress)

Responsible Team

Milestones and Timelines

  • (Key milestones, expected completions)

Challenges and Dependencies

  • (Any major challenges)

Success Metrics

  • (Potential metrics)