GitLab Foundations, 9 Aug 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Discussion on Pajamas - "French Vue", "English View" implementation and business value

Description

Christen and Eipi talk through what are the new ViewComponents, how can we make this simple for non-technical roles to understand and what is the business value of doing these conversions to product teams.

This will be refined into a better explainer video!

A

B

Perfect thanks.

A

Okay, so I just wanted to give some context, I'm going to quickly repeat what I just said um so uh kristen wants to know. There's a new thing on the block called the english view component.

A

It's a thing that we use in rails and uh kristen is asking for the business value of moving to it, and so I thought I'd give a little context of where we're coming from at gitlab and where we want to go right.

A

So we have a thing you know.

A

Basically, when gitlab started, it uses a template language like it's called hammer and basically it's just html and when gitlab started, people were just adding bootstrap classes to things you know, if you have like a page, let's say the issues page in the merchandise page, you add like headlines uh and you add, like badges and avatars based on you know: bootstrap classes.

A

This obviously grew over time and we have hundreds of pages, and so it's really hard to enforce consistency.

A

um One way to reuse code is so-called harmon partials, which basically is often used in the older parts of the code base. For example, if we're talking about issue builds like merge, requests and issues um certain aspects, let's say like the right hand, sidebar might be reduced via a partial or like other aspects like, um for example, the notes where we write our comments.

A

The comments section might be, you know, code, that's reused between a partial um that you know still means that if, in like dozens of partials, you have dozens of avatars there's a lot of repetition there. um One thing that's also there is a rails helper and a rails. Helper is basically can be anything right. You could have a helper that I don't know divides a number by two or you could have a helper that returns a little bit of html.

A

So one of the ways how we were writing, um reusable things like avatars, where rails help us, um and so now we basically end up with like we have like three ways to write things in from the backend templating perspective, and there might be a lot of duplication um and the rails help us have the downside that they're, like they're, not necessarily made for writing html.

A

So you know testing them might be a little bit harder, for example, and there is this new cool technology called view component and most of these three use cases might be able um to.

A

We might be able to migrate to them, so we can build pajamas components, uh view components, the english view, components that would be like avatar or even larger sections like card or empty state and all these kind of things, and so it's beneficial for us to use them, because we can actually currently they're all inside of the gitlab project, but we could also move them outside of the gitlab project rather easily, so that they could be reused across other projects like documentation or something documentation, customersgitlab.com and so on and so on, um and so basically these view components that we're now writing.

A

If they wouldn't exist, we probably would write rails helpers to be honest right, but um the view components have a few benefits over them. You can read them up on the view, components page that you probably link. I don't.

A

I also don't have all the details in my head right now, um but in the end we will probably have a component library that is uh an implementation of our design system, similar how we currently have and now backtracking here a little bit how we currently have uh an implementation already of our design system or large parts of it, and that's git lab ui, and that's using the french view, and the french view is uh the thing that we basically use for everything new or for most new pages for pages that behave a little bit more like single page applications for pages that load a lot of things, asynchronously we're using it already since years.

A

Right um and this.

B

If a team like, um if they convert their their part of their feature over to vue or have a single page app, they can just use the normal view. Gitlab, yes ui, which is the french view.

A

B

Probably the ideal scenario: if um yes, a lot of pages require hamel or ruby or like these older.

A

B

A

Biggest benefit that these english view components have and that all the harmal templates have over. Let's say the french view is that um for static pages that don't have a lot of interactivity, they're usually rendered right away right, and so the question is like for a lot of our legacy. Applications migrating them all to the french view is a lot of effort, and so actually, if we just want to ensure consistency, for example, that all the small settings, um all the sections on all the settings pages are rendered the same.

A

It's easier for us to move forward and move to an english view component, or you know if we want to make our forms more consistent.

A

These english view components give a lot of benefits over partials and templates because they allow you to be more strict about how the developer is using it and thus enforcing consistency and also having a single source of truth, where we can change things like if we, for example, in a form want to have like a loading state. After someone hits the submit button, instead of fixing 80 submit buttons throughout the app, we can just do it in one place um and and.

B

That's what you like the view component in hammer.

A

Yes, that's the english view component in hammer so.

B

Now one more thing: the english.

A

Component could for more complex, dynamic things. Let's say for a drop down. Could probably we haven't figured it out, but there will be and should be a way how we use the french view component so that we don't have a lot of um duplication between these two implement implementations, yeah.

B

So from a product manager perspective, if I don't have the roadmap, I don't have the time or the capacity to do the top option, which is migrate. All of my features to using view and be single page. We have this alternate way where you can leave them in haml, there's three different ways of doing the view component inside a hammel template, partial or with a rails helper, and then that allows you to get the newest gitlab ui rendered within hamlet and.

A

B

Just yeah like I wanted you to go through too just quickly. Currently, where are we at in terms of these, like component migrations with hamel, and why should we be excited about us that, as product managers for what we can do, then, with our uis like to keep moving forward on doing all these component migrations?

B

What are they getting.

A

Us so basically, these two, the english and the french view components they are definitely pajamas compliant and we moving forward if we ever change something on the design system, we're going to fix them in a way that doesn't require a lot of you know re-implementation yet again, or these kind of things you know or if we actually make them, for example, more accessible.

A

All these benefits will you know propagate to all the pages that use them um and uh yeah I mean that's, that's the main reason why we're moving uh moving to them right like to ensure that we are more accessible and more consistent in our uis. I mean this is the big benefit because down the road, if you open any page of gitlab, it should feel and look like gitlab right.

A

If you open any drop down, it should feel and look like the other drop downs in a gitlab application, so that users that have learned to use our application, you know, can just use about any page and understand how it's working and that there are no quirks uh between different pages, which we have because right now, a lot of our code is still fragmented between those three ways on how we do it is.

B

One of those three ways better than the other, or is it just case by case in terms of whether they would be migrating with in a partial and a template or with a helper.

A

uh Theoretically, any of those three uh can be pajamas compliant or can be written in the uh right way, but I kind of ordered them in the order.

A

How easy it is to make mistakes right, the top one, it's very easy to have like hey at one point, these 40 avatars look the same, but they don't look the same anymore to how um you know to to make it to you know, to have it a little bit easier right.

A

I'd have it uh so that it's easier to be compliant right, and um so, basically, I think, theoretically, the difference between a rails, helper and the view component is actually not that large from a you know, high level perspective, it's just that this english view component makes it a lot easier.

A

uh The developer experience is better and it makes a lot easier to test and other things, and so actually what we're sometimes doing when we already have a rails helper in place.

A

Rather, you know we actually just change the helper to use the view component under the hood, and so you don't have to go in and fix it in 80 places.

B

Right right away, so I already had put the helper in you- would go in and put that in the include or something like, so that the actual view component is there.

A

Yes, so so, for example, if we, if we have a rails helper for avatars- and we now have a view component for avatars- that we want to use people, uh people have used in a few that we want people to use in the future.

A

um The thing that we could do inside the existing helper we can, just rather than you know the template that we have there. We can just uh use the view component under the hood.

B

A

This is also a thing that we can do inside of partials. Right like this is like. If we have a partial instead of replacing the whole partial, we can replace parts of the partial with the view component and then every page using the partial will be improved a little bit.

B

So if we've done 500 migrations of a certain component, we've already rails helpers for that the good news.

A

B

We can just swap those helpers to pull in.

A

B

New view component, and so in our gitlab ui french view- we've got every component there are we going to have this every component built out in the view component way as well like there'll, be like one? That's in the french one in the english and they'd we'd, keep them both um up to date with new design changes.

B

A

B

A

Yes, so that's that's!

A

Actually the thing um where we have the potential plan of pulling out these view components so the english view components so that they're reusable and we might want to put them in the same repository as the french view component, so that we can ensure that if I have an avatar- and I give it a picture that the resulting because it all results in html- that the resulting html looks the same, I would not say that it's necessary that we have every component as part of a view component because, like if you let's, for example, say what are highly complex components like the filter.

A

Token search right, like the filter, token, search that we have uh on the issues list pages and merge request list pages um rather than having an english view, com. Implementation of that. um We would probably urge the owners of those pages to go with the french view from the get go right.

A

It's more we're currently targeting more static components like avatars labels, badges, um you know, maybe some layout things like cards or if you have column layouts, um but we are currently not targeting, and you know this is where we also need to have a discussion in the future like does it make sense to have like an english view component? That is a little wrapper um around a french view component. That is, for example, in drop down right right.

B

A

We are not there yet a hundred percent, but you know um we definitely should build a matrix, also and a decision tree somehow like. When do we build an english view component and I think the gut feeling right now is if we look in the gitlab code base and see that in these three we have dozens or hundreds of instances of something like an avatar or a badge.

A

It makes sense to build like an english view component for it yeah.

B

That makes a lot of sense. I know we're out of time here, so I should probably stop recording.