1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
|
---
stage: none
group: unassigned
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
---
# 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**
- **Working Group**: [Vue.js 3 Migration Working Group](https://handbook.gitlab.com/handbook/company/working-groups/vuejs-3-migration/)
- **Facilitator**: Sam Beckham, Engineering Manager, Manage:Foundations
**Milestones and Timelines**
- (Key milestones, expected completions)
**Challenges and Dependencies**
- (Any major challenges)
**Success Metrics**
- Using @vue/compat in Monolith
### 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](migrating_from_vuex.md) 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](vue.md#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](https://gitlab.com/gitlab-org/gitlab/-/issues/422903) 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](https://github.com/postcss/benchmark#preprocessors).
**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](accessibility/automated_testing.md) to learn when and how to include it. You can check out our progress with [Accessibility scanner](https://gitlab-org.gitlab.io/frontend/playground/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**
- **Working Group**: [Product Accessibility Group](https://handbook.gitlab.com/handbook/company/working-groups/product-accessibility/)
- **Facilitator**: Paulina Sędłak-Jakubowska
**Milestones and Timelines**
- (Key milestones, expected completions)
**Challenges and Dependencies**
- (Any major challenges)
**Success Metrics**
- (Potential metrics)
|
