DEV Community

Cover image for Vertical project planning for a Vanilla JavaScript/Rails app
Sam Markham
Sam Markham

Posted on

Vertical project planning for a Vanilla JavaScript/Rails app

When I was building my PokéTeamBuilder JavaScript/Rails API app, one suggestion I heard from my bootcamp was that to make things easier on myself, I should build my project out vertically instead of horizontally. It took me a while to really grasp what this meant, but when I did, it was very helpful to me for planning this project, and also as a project to-do list as I continued to add new features!

The Concept

If you plan your projects horizontally, which in this case means: planning all of your database models, then doing all of your database migrations, then all of your controller actions, then all of your data fetching on the front-end, etc, you're likely to have to go back and redo things, because you're probably not going to be able to guess everything all of your features need to do up front!

Vertical planning, in this case, means starting with one feature and taking it all the way from model to styling, and then moving on to the next thing. Working on my project, I wasn't able to apply this perfectly in practice, but that didn't matter--it still made a wonderful frame to work from, and made the work of setting up something with this many features a lot more manageable!

The Example

The goal for my PokéTeam builder app was to have an app that would let a user select 6 Pokémon and a Trainer Sprite, move them around on the screen after they appeared, and then then take a picture of the team for posterity.

There were a lot of moving parts here, but the first feature I started with was the Pokédex--I needed a drop-down menu with all of the available Pokémon that would be in the app for the user to select from them to make instances of individual Pokémon to drag around.

After making a new Rails API with rails new poketeam-builder-api --api, I:

  1. Set up the model
  2. Wrote the seeds file to get the data I wanted from the existing PokéAPI
  3. Set up the controller actions
  4. Wrote a fetch request on the front end to get this data into the view
  5. Dealt with the view logic--in this case, getting all possible Pokémon from the Pokédex to show up in six dropdown menus.
  6. (I did not deal with the styling until after the project, but, using this method, I really could have dealt with it here if I had been feeling less pressed for time!)
  7. Moved on to the next feature: allowing users to create an individual Pokémon to move around the screen.

This is what (part of) my to-do list looked like for this project--I highlighted boxes yellow once I had finished something.

Picture of the spreadsheet

Not everything is included here because I had more columns than would fit in this screenshot (the user model was next!), but this was the gist of it. Using this way of thinking through my project, I was able to save myself a lot of time and headache figuring out what to do next, and I'm really happy with how the final (for now!) app turned out.

I hope this is helpful as an illustration of the method for anyone interested in trying it out!

Picture of the PokéTeam Builder App
(The current version of the app!)

Top comments (3)

Collapse
 
akdeberg profile image
Anik Khan

@sharkham Wonderful journey as it seems 😀 Thanks for sharing it. Can you please share the whole project todo list? It would be a great help.

Collapse
 
sharkham profile image
Sam Markham

Thanks Anik! And this is the rest of the to-do list in this format--there were a few little things that didn't fit that I noted down elsewhere, but this is the rest of the overview and main functionality :)
trainer to-do list

Collapse
 
akdeberg profile image
Anik Khan

Cool 😊 Thanks for sharing; helps a lot.
Happy coding!