Clement Ho discusses GitLab's use of Vue for its frontend components. While many assume GitLab uses a single-page Vue application, its frontend is actually made up of multiple Vue applications. This structure was adopted to allow for iterative development as individual features are added as Vue apps. Over time, more components were rewritten in Vue due to its advantages around performance, maintainability and reuse. GitLab then created its own component library called gitlab-ui to further improve development velocity and organize reusable components. The challenges now include managing updates across GitLab products and decoupling the components from GitLab's CSS.

1. Building our
Component Library
Clement Ho

2. Clement Ho
Frontend Engineering Manager
GitLab - Monitor Health
Austin, Texas USA
@ClemMakesApps

5. When people hear that we are using
Vue, most people think GitLab’s
frontend is a Vue SPA

6. SPA (Single Page Application)
Frontend runs as one application on the client

7. GitLab’s frontend is
not a Vue SPA

8. Vue SPA Vue SPA Vue SPA
Vue SPA Vue SPA Vue SPA
GitLab’s Frontend

9. Why multiple SPAs?

10. To understand, we need to
understand the historical context

11. Fullstack Application

12. Fullstack Application
Backend
HTML
Templating
Transcompiles into
JavaScript

13. https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/assets/javascripts/create_merge_request_dropdown.js#L35-46
Problem 1: UI’s with high DOM manipulation was slow

14. https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/assets/javascripts/create_merge_request_dropdown.js#L35-46
Problem 1: UI’s with high DOM manipulation was slow
Bad Performance

15. Problem 2: State management was difficult to maintain
DropdownUser
DropdownAjaxFilter
FilteredSearchDropdown
Extends
Extends

16. Problem 2: State management was difficult to maintain
DropdownUser
DropdownAjaxFilter
FilteredSearchDropdown
Extends
Extends
Bad Maintainability

17. Problem 3: DOM and JS were often coupled

18. Problem 3: DOM and JS were often coupled
Bad Performance + Maintainability

19. All these can be resolved with
a modern framework

20. Modern Framework
Frameworks tend to minimize multiple DOM read and writes,
helps with state management and maximize reuse of components

21. Fullstack Application
Backend
HTML
Templating
JavaScript

22. In the spirit of Iteration, we started
with one Vue app for Issue Boards

23. Why Issue Boards?
1. New feature that was independent
2. High DOM interactions with drag and drop

24. Issue boards validated that Vue
would be our framework of choice
いちばん!

25. At that point, we could have decided
to convert the entire frontend into one
SPA

26. That would mean
no new frontend
features
for a long time

27. That was not acceptable for us

28. So, we decided to iterate

29. High DOM interaction
components => Vue

30. As we continued, more and more
frontend was written in Vue because
components are easily reusable

31. Our ~/vue_shared/ kept
growing

32. We decided to build our own
component library

33. Problems we hoped to solve
1. Increase velocity of our team
2. Create an organized system to see reusable
components

34. We started our component
library in Jun 18, 2018

35. First component added
in July 26, 2018

36. We began
1. Moving some components from vue_shared
2. Creating common components for the team to use
that were styled and ready to go

38. Why component wrappers?

39. Encapsulation

40. Where are we today
(1 year later)?

41. We have 42 components

44. What are our challenges?

45. Difficult to manage hot fixes and
security releases with gitlab-ce/ee

46. gitlab-ui is quite coupled with
the CSS from gitlab-ce

47. What do I foresee in our
future?

48. 1. More components (quantity)
2. More reliable components (better test coverage)
3. Used in more projects besides gitlab-ce/ee

49. If you’re interested, we are always
open to community contributors for
gitlab-ui :)
https://gitlab.com/gitlab-org/gitlab-ui

50. Thank you