Overwatch Stats: Creating a simple JavaScript App

The original plan for this blog was to implement a very basic Angular app, and then share the process and result with you. And while I did implement that app, and I will show (a version) of it to you all soonish, the recommendations I got from people who reviewed the app were that it was a worthwhile learning experience to build it in pure JavaScript/jQuery. So I did, and it was a pretty interesting project that I thought others might be interested in. It’s still missing a couple pieces (primarily error handling) but as those are implemented in the Angular version, I’ll leave them for that blog.

My focus in building the app without any MVC framework was to understand the ideal logic flow of the code, under the hypothesis that such an understanding would improve my ability to use an MVC framework like Angular more effectively. This meant trying to optimize the modularity of my code as well as strictly following the design patterns recommended by my teacher.

MVC!

As previous blogs have mentioned, MVC stands for Model View Controller, and it’s a popular design pattern for websites. The Model holds data, the View translates the data into a palatable GUI, and the Controller allows the user to interact with that GUI.

We will be using a very similar structure for this project, adding in one addition for maximum modularity; the adapter. The adapter make the asynchronous API call and passes the data to the model. The model is updated with the data, which then updates the Controller, which then updates the View.

The User adapter (for aggregate and average data)

This is the adapter itself — it takes in a user’s battletag, calls the Overwatch API with that tag, and returns the results, which are separated into average and game (aggregate) data. I used jQuery’s Ajax function to do the asynchronous call, and then its methods success and error to handle the potential results. On the success case, that data is then moved into a new model, which is in turn added to the store. The model is given aggregate and average data for the user, or character data, depending on which request was made.

The User Model

The controller takes in button clicks from the user and runs them through a series of functions to determine what the user is inputting, request the relevant data, and respond on-screen with the appropriate information.

The router tells the viewData function which options the user has selected (# of users, general data vs character data)

Let’s take a quick look at the front end in order to see where those inputs are coming from and what options the user has.

The landing page

The router gets all its info directly from here. The two user input fields supply the battletags that are used in the AJAX calls, the three options determine which adapter function is used. Average and Overall stats go to the userAdapter file, whose API call returns both aggregate and average data, while the Character stats goes to the heroStats adapter.

Once the AJAX call is finished, we’ve created instances of the User model to hold the data and stored them in the store. That gives us access to the information in the Controller, and we can step into a couple of functions that parse that data into appropriately structured HTML. Append that HTML to our containers, and we’re ready to go!

The app can be found here; the Github repo here. Thanks for reading, and I’ll catch you later for Angular, React/Redux, multithreading, and more!