 just make sure the recording is on this is my first recorded zoom call so hi youtube or whoever's watching this so this is gonna be fun uh share my screen and then we should be good to go um thumbs up you can see my slides awesome so i'm just getting the chat open just in case you know what's the chime in there but yeah so welcome um talk is named from legacy to view j s uh it's gone let's let's let's walk through it i'm denis i'm the front and engineering manager for managing growth and i've been at get lab since march as you can probably indicate from my contribution graph and uh i'm here to talk to you about the next javascript family kit get lab no i'm just kidding we're gonna talk about view and how we apply view in the context of manage and i originally wanted to name this our journey of how we're moving from rails automatic javascript to view j s the feature costs involve the technical debt along the way and how to stay sane while developing the front end at get lab while still delivering on the second 20 second every month sorry but the title doesn't as you can tell really flow and uh leon actually suggested that the title would be how we do view j s long before i even put this presentation together but it actually kind of evolved back into that title because really what we're going to talk about is how the managed team uses view j s and kind of the challenges we encounter uh developing on the front end as well as kind of some workflow improvements we've made to kind of make that a little bit of an easier process um this is not your typical managed 201 um this won't really be covering any specific feature but just front end in the context of manage at get lab um it's a little bit of a kind of end of your retrospective for the team as well as in addition to it being a little bit of my experience a summary of my experience at get lab um and hopefully uh any audience will find this somewhat useful i think for front ends especially onboarding front enders um there'll be a lot of tips and things that we kind of discovered that i wish i could kind of known a little bit uh earlier when i started that is not always uh so documented and um but also be useful for project project managers uxers and pretty much anyone inside or outside of get lab uh into getting some insight on what's involved with developing the get lab front end as well as understanding why some front end changes while they may seem simple can be a little bit more difficult to execute on um there's really no code that we're going to be going over other than some contextual uh illustrations to to highlight some of the history of front end at get lab but we can definitely dive deeper in a later 202 or so on session if we want to take a deeper look at things um on that point we do have a lot of good talks by Philippa, Phil, Fatih, Tim, Lucas on how we use Vue and Vuex specifically and diving into code so if you're interested in those uh please ping me and i can send over some links um but they're also available on youtube um for those of you joining on the recording or some uh if anything i've been saying so far hasn't made any sense uh if you would like a one-on-one or a one-on-two on Vue.js at get lab uh i've added a couple links here uh some really great presentations by Jacob, Tim and Lucas on how we do Vue.js at get lab and a little bit more of a look at our art front end uh architecture so jumping into it our agenda for today is we're going to go over a brief history of front end at get lab feature costs how to identify them with some examples as well uh estimating front end work some of the challenges we've had some of the improvements we've made to try to break things down in terms of deliverable scope uh what's next for manage front end and uh maybe get into some questions um please feel free to jump in at any point in time if you have a question i'm happy to chat and it would be awesome to have this more of a conversation and uh for the front enders that are on the call feel free to jump in add some context or maybe correct me any errors i may have made um so jumping into it a brief history on get lab uh sorry a brief history on front end at get lab where do we come from where are we going so for those that aren't familiar uh get lab was built uh with ruby on rails which came included with coffee script in jQuery and so coffee script solved a lot of issues with ECMAScript 4 and 5 where ECMAScript really wasn't pulling its weight uh and so it really just was there the right tool at the right time but since the introduction of ECMAScript 2015 and 2016 and so on uh i think they're now just known as the yearly versions or ea6 or ea7 the modern java script has really made a lot of improvements along the way which has led us to uh allowed us really to move away from coffee script but there was a little bit more involved with in addition the coffee script where we have inline java script where it served its purpose for small interactive features but can be very very difficult to manage when you have a more complex application or some interactivity that needs to happen on the same page that's not to say that we don't need inline java script from time to time we'll dive a little bit more into that but um it you can immediately see when you have this java script next to a giant page template how this can be quite difficult to manage once you get into more uh single page applications with handling a lot of state um and as part of our migration from uh coffee script we ran uh we just completely compiled everything from coffee script to uh ECMAScript 5 since when you actually run coffee script that's what it transpiles down to so we just had a mix of jQuery and java script uh and ECMAScript 5 so the thing the nice thing was that there was a clean migration there's no broken tests because literally functionally nothing has changed and then we wanted to move to the next step which is just moving to plain java script vanilla java script uh and manually writing uh ECMAScript 5 to ECMAScript 6 on a as needed basis so we still use jQuery uh you know currently and actually before we wanted to move to Vue.js we wanted to consider using continuing to use jQuery because it handled things like collections nicely um when ECMAScript 6 was still kind of getting more features added to it and um but ultimately we decided to move to Vue which is kind of where we want to move all of our fun and features to uh and be able to encapsulate all of our components and applications into these composable single file uh components where we can have all of the wiring all of the data going and and all of the templating for given component application um more clearly organized in a more component structure um additionally we have another um actually so just to recap um coffee script is gone inline JavaScript is mostly gone we still have some cases where we still need that um but all of our code exists as jQuery ECMAScript 6 or Vue. Now there are still areas of our code base that are a mix of Hamel and jQuery uh and that's not necessarily a bad thing we like Hamel um it's kind of the intersection of the front and the back end where a lot of the back end data that we need right now is fed through as Hamel um or html attributes uh that get fed into our JavaScript and Vue applications now um we do want to get rid of jQuery but there are some strings attached to that we do have some downstream dependencies such as like two and I believe bootstrap still relies on jQuery that we need to or at least the flavor of bootstrap does um that we need to kind of take care of before we really get rid of jQuery and just completely rely on uh plain JavaScript as well as Vue but the main goal is that uh we're moving to or the main idea really is that we're moving to Vue.js but we need to be pragmatic about it and we'll kind of dig into a little bit later what that means but as far as the history of frontend at GitLab are there any questions and unfortunately my emojis aren't showing up on my slides let's move on so this is getting more into the workflow thing um I want to talk about feature costs and how to spot them but first what are feature costs um they are things that can cause they can add to an issue's weight and influence our ability to deliver on them so what do I mean this is actually one of my deliverables uh that was merged into 11.6 but you can see these red little labels here missed deliverable and the missed amount of stone tags and so feature costs are things that can influence uh and and cause you to miss your deliverables so it's more specifically it can be things like technical debt um cross team dependencies uh unforeseen requirements things that we may not have discovered until halfway through the issue um and maybe a disparity between how our open source edition works versus our source available edition works and maybe unaccounted features that that may exist in EE that we have an account for when we were working on it in CE so earlier I said we're moving to Vue.js but we need to be more pragmatic about it so what does that actually mean um so we always want to scope things as a minimum viable change uh so they're moving to Vue.js is very important but we have to make sure that we're not refactoring for the sake of refactoring and choosing to refactoring uh can really add to our ability to be able to deliver on a feature and we want to get there but we have to also continue to deliver value and deliver features to it to our users so the main goal here is that we know we want to get to Vue.js but it may not be possible to get to Vue.js in one iteration but if we can get one step closer or one iteration closer then I think that's something to keep in mind when we approach our deliverables and so that's why it's always important to scope things as a minimum viable change so some strategies when we're evaluating deliverables can uh I have here and hopefully it's a little bit easy to read it's kind of cause and effect so looking at something and thinking back to our layers of JavaScript in the front end if we are just doing simple table listings or empty states then we can just really keep it simple and just stick with Ruby and Hamel and there's really no JavaScript that's involved there if we need an interactivity then we need to figure out what layer are we working with what layer of JavaScript does this feature exist as is it still jQuery is it a vanilla JavaScript or is it already a Vue component and then once we decide okay well maybe the component or the application can be replaced or reused and we can do it in a reusable fashion then it makes sense to to convert it to Vue and of course if you're managing state across components and it gets a little bit more complicated and you're dealing with state across components then it makes sense to add on Vuex but a couple of things to keep in mind when we're working on these front end features is to minimize the use of of jQuery we want to get away from it we don't really need it as much as we do anymore and so we should always try to prefer a vanilla JavaScript of course one exception here is if the file is predominantly jQuery then it may make sense just to continue using jQuery but even then it's always preferable to just stick with vanilla JavaScript so at least there's a little bit less to convert when we need to completely move it over so examples of feature costs I'm going to go over a couple of deliverables completed and ongoing with manage that kind of speak to the way we have to kind of evaluate these these deliverables and how we kind of approach them and there's some lessons learned as none of them not all of them are the greatest examples of estimating and breaking down so the first one is the project list UI redesign so we wanted to take our existing project list and give it a little bit more data a little bit more interactivity and also just make it look a little bit nicer so looking at this we know that we have this data before because we have these in our project overview we can see that we have a star control which is already exists so if we look at this we can tell that is the data there you know we check it make sure that it's available and we can surface it through our hamel templates make sure there's no back end dependency that we need to do to actually get that data but overall there's no new functionality that is in present elsewhere so our result is that we only really need to make hamel template and css changes so we don't have to convert this table to a giant view component it's just kind of doing along with our get lab principles it's just keeping it simple using boring solutions we've just made some minimal changes possible going forward another example is our import project status table UI refresh we wanted to give this a little bit more statefulness give a little bit more interactivity and actually give it a little bit more information and as well you know okay make it look nicer but the main thing was that we wanted to also make it more maintainable so in this case while we added statefulness and you know when we can tell when the project is running or when something's done and we can go to the project we also realized looking at the code that was quite old and difficult to maintain and so kind of somebody summarizing this all up when we needed more interactivity and we wanted to improve the maintainability of the implementation then it made sense to convert it to view and view x moving forward we had a group level project templates and this is actually kind of the example where we currently kind of need inline JavaScript but this one is we'll be shipping in 11.6 and is a follow-up from our instance level project templates so really there's not much difference between instance level product templates and group level project templates the main difference is that you can obviously in group templates have multiple templates that belong to a subgroup but overall the feature is primarily the same now that's not to say that on the back end there's still work that needs to be done because there definitely was but on the front end side of things there was a lot of existing functionality that we could leverage and so again we went with the boring solution we quite literally copied the solution from instance level project templates and added the minimal JavaScript we needed to be able to have that expanding collapse functionality and so this is one final example which is my favorite which I won't forget at GitLab because this is an example of how things can go wrong and how you can estimate things or want to refactor things and really just kind of have a snowball effect where you have a deliverable that misses cycles repeatedly and so the concept of this was quite easy we have this project dropdown which allows you to see your frequently visited projects and we wanted to copy it over to the groups tab and just show you the groups that you visit the most so this was quite easy there were no dependencies the data was already there and my manager actually advised me to just copy and paste the code from frequent projects but I decided being near to GitLab and wanting to really deliver as much value as possible to decide to consolidate all these components until one right why copy the code why have duplicate code when we can just make it easier and have one component handle it for both but along the way I also decided let's convert it to view that was all good and then I said well there's some statefulness involved with this I can use the actions to retrieve the frequent projects and groups I can use some mutations and and really get VUX going here so I decided to add VUX on top of it and what ended up happening was a what should have been a very simple task turned into something that lasted between I think two early cycles so it was definitely something that I learned and that really inspired me to kind of put this this presentation together to really understand that yeah we really need to be pragmatic about how we migrate things to view and how we get there and also understanding the scope of the given deliverable and how we really want to approach it but to recap in terms of feature costs and how to identify them and how to how to really approach it you know pick the best approach that makes sense to you it's something you really need to talk with with your product manager UX counterpart as well as your backend and front-end teammates as well to figure out what data needs to be there what what changes need to happen and maybe if it has to be a refactor can it be broken down further is there you know more of an MBC somewhere in between and all that's just to figure out how we can design your next iteration to be a step in the right direction to get things like VUJS and it's it's obviously okay to be ambitious but it's also important to you to have a gut check and be a little bit more realistic as well so any questions about feature costs so far then we will keep on going estimation is hard but we can make it easier so these are kind of the tips I I wish I'd known or kind of reminded myself repeatedly uh when I was first starting out and that I do now when I approach any deliverable um and so these these are ways that you can identify these feature costs and how you can identify dependencies and figure out okay does this does this issue really need to be broken up more or is there something I need or is there somewhere else I have to check so just jumping into it we've got a front-end development process this kind of checklist of all these things that we can do when we're planning and executing development of a front-end feature there's a link to this later on and it's quite exhaustive I would say uh and all the points are quite valuable but there I kind of have a top I think it's like eight or so that I really ask myself for each deliverable and then I can dial a little bit deeper if these questions uh really cause more questions um so the first one is what is the feature composed of is it primarily Ruby is it uh does it need back-and-support are there helpers for this as there is your data I need to surf this is it actually stretching into an area that maybe I need some back-and-support for um is it primarily jQuery vanilla JavaScript view a little bit of mix of the all the above uh it could be very well uh possible that what you're working on um is a big combination of it so it's really important to figure out what's what's the best move to still deliver the feature but not be caught up in converting everything to view for example and uh this really leads you to think uh whether you should consider breaking the issue down um and especially for front-end it may make sense to have separate UX and back-end issues if there's data you need and you don't know how to interface with the back-end or it's not available on the API um if there's UX specs that you need that um you know you really need the full UX spec before you can estimate the front-end work involved and know that if you're working on something for example like uh project overviews do you need to worry about uh the geo features the project mirroring features on the enterprise side of things um and that and just going back to that that may actually mean that uh like these UX and back-end uh ticket these issues might have to be like a release before you actually go in and and execute on your work and and that might be okay but taking a look at all this and what's involved with delivering on your your feature uh will at least help you identify that and makes it easier to actually make that case uh for splitting things up and maybe scheduling things a little bit differently another question worth asking um when you're breaking this down is how much interactivity is needed does it even need vjs um is it a drop-down one kind of perfect example of technical debt is that we uh have four different uh job drop-down libraries so which library do we need to use um we want to get rid of all then we would love to have just one that does it all for us but certain ones solve different use cases and i have my night mode turning on so let me just switch that back sorry about that um but yeah it's just trying to figure out um how much interactivity is actually needed and determining how much JavaScript you actually have to write to achieve it um what already exists that you can use um what components from bootstrap 4 and git lab ui are available uh and i'll get a little bit more into some ui resources that are available to us uh that we want to try to utilize as much as possible such as our design system css lab our css framework and git lab ui our view bootstrap component library so taking a look at what you need to deliver on and what is available to you uh and trying to figure out how much how little you actually need to do or how much or what's what's the diff between what's available and what you need to actually do to achieve the feature um is is a great question but also one thing worth asking is if there's existing code does it make sense to migrate it to css lab or git lab ui um and so getting into our tools a little bit it's a little bit of a break between these approaches is uh our tools that we have as front-enders available to us so we have pyjamas our git lab design system with all of the components and all of the methodology and the reasoning behind our typography our components are things like our popovers how we do models and things like that which is heavily leaning on bootstrap 4 but also with the git lab flavor kind of mixed into it um we have git lab ui which is our view bootstrap framework uh which you have links here to check out our storybook uh to actually be able to interact with the components and uh change the parameters around that and then we also have css lab which is our uh css framework that we're slowly migrating our existing uh css over to um to uh hopefully kind of be our comprehensive and our single source of truth in terms of our css across git lab ui and other lab uh applications perhaps as well um and another question to ask when you're evaluating deliverables on the front end is is the data available uh from the back end and that means can you make the right uh can you right make the right queries to surface it in the controller to expose it in the hamel templates or is it available on the api should it be available on the api more often than not maybe we want to have that available not only for the front end to consume but for api users as well and we've also got graphed ql as uh when we want to query for additional data which we're slowly starting to use as well so these are all different questions and this is like a big dependency of course with front end of you know is there back in data available or do i need back in support or do database support to really get what i need to build this feature um and the big one of course is how does it behave an enterprise edition kind of touching this a little bit but you have to check how the feature differentiates between c e and e and this is especially important when you're getting ux specs and uh there may be some hidden un uh unconfigured options or features on the enterprise edit things that you have to really look in the code to identify things like geo or project mirroring uh or impersonation which you don't really these are tucked away and you don't really use them uh very often but can be uh quite important when you're redesigning or doing a page overhaul or adding new features that make conflict with these existing enterprise features and it's also just good just to check twice um which is why i put are you sure because it can definitely come to to haunt you if you don't account for the different uh feature the feature differences between c e and e and then one thing you also want to check out is uh whether you need to manage state in your application and uh we try to manage event state within our view components uh but we want to avoid using event hub because at that point your state is probably getting complex enough or you're having to manage uh state across multiple components in a given application and um you at that point you'll want to use ux uh and we have a lot of resources in our front-end guidelines on how gitlab does ux um and this is the last point tests um you got to check if there are any uh and we have to account for it in unit tests of course but also check our functional r-spec tests see if where the existing ones are and if we add we have to add new ones and then of course with view x there's a lot more testing involved there making sure that our actions mutations getters and setters are all accounted for as well um thankfully we have a view cli that felipa is working on that will make a lot of the boilerplate uh creation a lot easier but the main point for all of these different questions that we ask when we look at these deliverables is to figure out how we can break these issues down into as many pieces as possible um this really helps us with our ability and our confidence to be able to deliver on on things and this is things that we've these are things that we've accounted for and had to realize working on manage uh because there may be dependencies we miss or hidden requirements that we didn't see at first glance and so it's really important to try to figure out uh and answer these questions because it will determine how heavy or how much weight your deliverable may have and there's a link at the bottom right there to check out our development process checklist um if you're interested but it's also in our resources slide um towards the end of this deck any questions cool so we're on the tail end here um and I realize we're a little bit over but I'll try to uh hurry it up um but what's next is uh not it might surprise you but we just keep shipping we move fast and we continue shipping the minimum viable change but along the way we can improve our processes and our workflows but the main goal is that we just continue to move towards the ujs uh but make and then slowly but surely bring our code into the latest standards and guidelines it kind of opens uh that's right sorry I thought it was at three um not three thirty thank you for the reminder um but I don't think there was anything that I missed on that last one um it's it's really no surprise there we just have to keep shipping but we have to uh just continually improve ourselves uh when we break down deliverables and uh try to identify these feature costs as much as possible um some questions to ask ourselves too which is kind of a little bit excited uh exciting maybe um for some of us is you know as we move away from hamel and and ruby you know what we need server side rendering if we need to worry about kind of the content when we first load pages um obviously performance is a continual question on how we continue to deliver the better user experience while we have these different layers of JavaScript and uh one conversation that I know is kind of happening right now I'm not really sure the current status of it but is you know does GitLab can start to operate API first and does that mean we have to create kind of a bigger single page application that the that will be the GitLab UI and then interact with uh GitLab as a as an API um there's also other topics that we can dive into like progressive web apps and like we're moving towards just for faster testing and better testing but uh yeah it's just um it's exciting so to recap it's kind of hard to recap all this um and it might seem a little bit all over the place but really it's just about our experience developing fun and on the managed side of things and some of the things that some of the challenges we encountered with dependencies with deliverable deliverables how to estimate things and and it's going to be increasingly important that we get these things right uh as we start to measure throughput as we want to be more predictable and be able to do things like deliver on a majority of our our deliverables you know if we want to say we want to hit all of our p1s and some of our p2s and so on it's going to be really important to uh really get these things right or at least get better at it because estimation and these features are never similar so we can estimation can be all over the place um as i'm sure you may have encountered yourself uh features can encounter a number of road bumps that will cause you to miss release cycles but that's a way that's okay um i think as mentioned if we continually improve our process uh then we will over time get better at it but if we do our due diligence of breaking down these deliverables uh and asking those questions on how to identify these feature costs and trying to get these dependencies taken care of then the amount of surprises can can reduce it's not foolproof i think we will continue to encounter things along the way but uh the more effort we put into it at least the higher level of confidence we can have and um here's some links to our guidelines development process uh i will update this to include links to git lab ui css lab as well as our design system and also some uh user names to ping if you want to talk to the manager front end engineers otherwise there's their channel on slack and that's it so hopefully you found that useful again some of the challenges we've encountered uh building front end a lot of us on manager quite fresh to git lab and so hopefully there were some useful tips or strategies that can help when you're looking at your deliverables for git lab but um any questions feedback comments on any of the material yeah i i just want to say thank you i started last monday so it's kind of that was nice just to see kind of like a big picture um kind of from the very very beginning kind of started talking about the various technologies you guys have used over time and the migration over time as well that's something i just wasn't really aware of so it's kind of interesting to see that and so yeah i just appreciate the the info sharing for sure for sure yeah um i would highly recommend checking out jake's presentation and that 101 slide that i put together he goes into a much much deeper dive into like because he was um with a lot of other front-enders they were there when they were converting from coffee script to es5 and then writing manually rewriting things these things back to es6 and so on so there's a lot of background information there uh which i put as a 101 he happens to be my manager too so that's kind of handy i guess even better cool any other questions any other feedback awesome well thanks for tuning in uh for those that joined live uh thanks for watching for those who are watching the recording uh i hope you found some of the information useful and hopefully it's we'll continue maybe we'll do a new one once we kind of refine the process further and and front-end continues to evolve but other than that um i wish you good rest of your day give you back 35-ish minutes and uh see you in the next one cheers again to you take care