-
Notifications
You must be signed in to change notification settings - Fork 0
Project Rundown
The main two projects at the moment are Apply and Apply-Admin. These two projects basically manage the two sides of the ‘applying’ part of the hiring process. Apply is a SPA in which candidates can sign up for an account and apply for a role. Apply-Admin is an SPA that allows admins here at the JAC (ie EO’s AO’s HEO’s that run the exercises) to create an Exercise. At the JAC, a vacancy is called an Exercise. These two projects have been styled so far in accordance to GDS guidelines using GOV.UK styling.
In both projects, we use Vue.js as a frontend Javascript framework to help build out our SPA, and Google Firebase to store our data as a database / cloud backend. We keep the main code under the src folder. We keep all our tests (written in jest) under the tests/unit folder. This folder should follow a similar layout to the src folder. We lint with ESLinter. Outside of these two folders, we have all our configuration files and dependencies.
-
The
main.jsfile acts as our entry point to our Vue instance. -
App.jsis our main component.App.jsholds some styling that applies to every page, and also has a router-view tag to render all the other components within it. -
main.scssimports the GOVUK style guide. In here, we also add any global stylings we want to use, in order to make our app more inline with the JAC aesthetic. If you find you're using a self made style class a lot, add it here to make it global across the project. -
router.jsis where we keep all our routings. This is a typical Vue router that lists all our routings, and some stuff about signing in etc. -
store.jsis where we keep our Vuex state store. This basically makes one place where we store all the states of our variables. Our database communicates with the Vuex store in order to send our data, and cushion the response - by this, I mean that data from Firestore is set to the Vuex variables, which we then reference in our pages. This way, we don’t directly manipulate any variables in the database, as Vue cries about that if we do it. -
Components folder - We’ve made some GOVUK styled component replicas which allow us to easily import the things we need and slot them in. This saves us writing out the full HTML in our pages, and it also lets us screen and vet our data that comes in, plus it’s neater. There’s a bunch of stuff under here, such as regular
TextFieldstoRepeatableFields. There’s some low level documentation in this file about how these components work and such. If you find there’s a need for a new component, then add it in here. Use the styling from the GOVUK design website and if there isn’t one on the website then idk. -
Helpers folder - This contains a few little helpers that we can import. These are mainly for the components for the moment such as things that vet the time and date and things that make sure our data is either a boolean or a null. Again, if you need one, add it.
-
Store folder - Okay so in here is where we hold all the stuff to create our database. I think the convention is to have a folder per collection? We’ve currently got one under apply-admin for exercises, which has code in there to create a collection and a document if you want an example to go by.
-
Views folder - this is where we keep all the page components. Try to keep this organised but generally this folder holds all the actual ‘pages’. With Vue components, you have all the HTML under the template tags, all the javascript / logic stuff under the script tags and all the CSS under styling tags. Use a scoped style tag in these pages in order to only have your CSS be applicable to that page. If you need to use it on more than 2 pages, I’d make it global and add it to the
main.scss.
For our workflow, we tend to work off branches which we merge into master. There’s no naming conventions or anything but it might be wise to name your branch something that relates to what you’re doing. Make sure you only push stuff that’s been linted and is passing locally run tests. Please also ensure that your Pull Request message is super clear and describes what you've done. If there's anything you're unsure about in your PR then mention it here (or speak to someone before you make the PR).
We use Git / Github for version control. Our projects can be found under the JAC Github account We have a merge block on that requires your PR to be reviewed by at least one person before you merge it.
Ideally, once you’ve made a PR, Let someone in the Dev team know that you’ve got a new PR. Someone should review it pretty much asap as we’re not about being blockers. When you review, if you have any questions or comments feel free to speak directly to the person about them, although if you request any changes these need to be written up on the files changed tab, and click ‘request changes’ to ask the dev to go back and change some stuff. If you’re happy with it then approve.
If your PR has been approved, just check with anyone in the dev team who didn’t review it if they’re happy for you to merge. We have a CI/CD tool called Circle CI which also spins up your branch and tests it. This needs to pass in order for you to merge it too. Mostly it’ll fail if you haven’t run the linter on your code or if your tests don’t pass. Circle CI gives you good info under the details tab though next to it’s failed test notification. It also tells slack when your branch has failed too so if you need to go into the digital dev alerts channel and you can see your error message there.
We use Trello to manage our workload via tickets. What we usually do, is every 2 weeks we will plan a sprint - in which we’ll sit down with the Delivery Manager/s, and maybe someone from UX, to organise our workflow for the next two weeks.
It’s super important that we write informative and clear tickets for what needs to be done, so please put as much effort into that as you can. Tickets usually include a description of what needs to be done on what project per page (unless the task is too big and needs to be broken down further). There might also be a list of things that need completing as part of this ticket. We also have little labels we can attach to tickets for full clarity.
The columns are pretty intuitive, however speak to someone if they don't make sense or you want to change them. You are responsible for the tickets you pick up, ie you need to add yourself to the ticket you’re working on, move it into the ‘in progress’ column when you’re working on it, and move it to ‘done’ once it’s been approved and you’ve merged your work.