DEV Community: Lauren Hoock

Trackside - A React Learning Project

Lauren Hoock — Mon, 04 Jul 2022 01:45:05 +0000

Alright, confession time. I have some hobbies outside of Flatiron School's Web Dev bootcamp.

I'll pause here for your gasps of disbelief.

While it's true that my hobbies have taken a backseat to the struggles of working through a bootcamp while working a full time job, that's not necessarily a bad thing. In this case, it provided the inspiration for a React project to solve a problem - namely, giving me access to abbreviated, concise, and concentrated information about the current FIA Formula One racing series. Why crawl through pages of search engine results to get a picture of what's going on in the world of Formula One when I could just build an app to aggregate and display that data for me based on a set of selection criteria? And thus, my Flatiron Phase 2 project idea was born.

There were a series of challenges associated with writing this app, mostly stemming from this being my first full-fledged React app.

The first challenge - Getting a bunch of Formula One data. There are several external APIs out there that will happily provide all the Formula One data you could ask for, but as a #codenewbie, I settled on the excellent F1 API from API-Sports as providing the right level of data for my needs along with extensive and clear documentation that even I could follow.

The second challenge - Storing that data. I'm using this JSON-server template as a backend for the app.

The third challenge - Determining the overall structure of the React components. The directory structure went through several iterations while I was building this project out, so this is something I'll be paying more attention to in the project planning phase in the future. The app uses a fairly straightforward structure, with every component referenced as a route by react-router stored in the /src/routes directory, and all other components stored in the /src/components directory. I also added a testData directory with importable JSON data from external API server requests to allow me to build out the visual part of components without having to hit the API for information on every reload.

The fourth challenge - Determining what components would be stateful. This has been my absolute nemesis while learning React, and I feel like I still have a lot to learn to avoid overusing state in components. Trackside has three stateful components, specifically, App, Drivers, and Results. To break down what each component stores:

App has three total states: two to track scheduled events and available years for data requests retrieved from the external API, as well as one that syncs with the data from the local server to store IDs for events that the user selects to add to their watchlist. More detail on this later.

Drivers has three total states: two to store driver and team data returned from the external API, and one to control the form data of the child filter component.

Results has three total states: two to control the child filter component, and one to store data retrieved when a search is submitted through the child component.

I feel like there are some opportunities for refactoring the components to reduce the amount of states in the application, but as this project was limited by available time, this is the iteration that I chose to stick with to develop a working release.

With the structural information out of the way, let's move on to the user experience. The basic idea for this app was to allow a user to view data from the external API pertaining to both the current and past Formula One seasons. This is accomplished through several navigation options in the app:

Drivers shows a page with a filter option to select a season. When the user selects a season from the dropdown and clicks Get Drivers, a request is made to the external API which pulls all of the team and driver information from that season, and the data is rendered in a format that shows every team that competed that year as accordions. When a team is clicked, it shows every driver that raced for that team that particular year as a card.

Schedule filters the external data using the current date to generate a list of events happening in the future. When an event is clicked, the race information is populated, along with additional clickable accordion options for the practice and qualifying sessions pertaining to that race.

Results displays a page with two filter options, one to select a year, and the other to pick either teams or drivers. Selecting a year and a type of data displays the final or ongoing standings for that year's Constructors and Drivers championships.

Finally, Watchlist contains an aggregated list of events from the Schedule page that the user has clicked Watch on. Clicking Watch posts that event's ID to the local server, and the data from the local server is used to display an accordion item for each event that has been watched, allowing a user to keep a list of events they're specifically interested in in a single location. The data is displayed in a similar way to the Schedule page, except with the Watch button changed to a Remove button, allowing the user to remove the event from the list.

And now for the fun part, the to-do list. This app ended up being one long lesson in managing feature expectations based on available time, and one takeaway that I have is that it's impossible to call an app finished without having more ideas for features and their implementations. In this case, there were several areas I had to cut short or implement abbreviated versions of features that I'd like to add. Specifically, I'd like to expand the application using the existing rendering methods to pull information not just from the Formula One series, but from Formula Two and Three competitions as well. I'd also like to expand the Driver component to allow the user to watch individual drivers, aggregating their stats on the Watchlist page under a Drivers accordion section, but this feature wasn't possible with the data being served by the external API. I'll need to work with a different API for that data, which will require a bit of refactoring. I also need to redo the app's styling- ideally, I'd like to write the CSS from scratch to better fit the mental layout I have of the app, but time constraints meant using Bootstrap to focus my time on developing the functionality.

That wraps up my companion post for my Flatiron Phase Two project, Trackside! Thanks for reading, and as always, suggestions for improvement are always welcome. Check out the deployed site at Trackside, and if you'd like to view the project's source code, check out the repository here.

On to the next project!

My First Web App!

Lauren Hoock — Sun, 22 May 2022 04:31:48 +0000

It's Phase 1 project week at Flatiron School for my Amazon Software Development cohort, and anyone who's been through a bootcamp knows what that means - borderline overdoses of caffeine and a complete disregard for every bit of scientific research claiming that sleep is necessary. I'll preface this post by saying that it's still early days in the course, and that the application presented here is a summation of what I've learned so far, but is by no means meant to be a professional attempt at creating a web app. It's necessarily amateurish, because I'm working from the knowledge we've gained so far, and any experienced developer looking at the code behind this app will probably have an absolute fit. However, with that disclaimer out of the way, and with no apologies for the absolutely terrible pun in the name, I'm extremely proud to present my very first functioning web application, Gotta Fetch 'Em All!

Blastoise looks as smug as I feel about making this thing actually work

Gotta Fetch 'Em All is an application built to demonstrate basic HTML, CSS, and JavaScript functionality, mainly based around showing fetch requests to both an external API and a local server, data persistence, event-based actions, and DOM manipulation. The app uses the public, RESTful, PokeAPI for external data requests, along with a Flatiron json-server template for local data persistence between page refreshes. The application relies on the local server being up and running to fully function. I used CSS Bootstrap for the baseline CSS formatting, but the remainder of the code was built from scratch.

The idea for the project revolved around creating a simple web-based implementation of a Pokemon game by pulling data from the PokeAPI and displaying it to the user, with options for catching, releasing, renaming, and running for your life from Pokemon, as in the real games. Specifically, I wanted the user to be able to:

See a random Pokemon pulled from the PokeAPI
Interact with said wild Pokemon by choosing to attempt to catch them, or by running away and having a new random Pokemon pulled and displayed
Collect Pokemon in a basic implementation of a Pokedex
Rename any Pokemon in the Pokedex
Release any caught Pokemon
Maintain their collection through page refreshes

I have several stretch goals that I simply ran out of time to implement, but that I'm looking forward to retroactively adding, including:

Error handling. My time was too limited to go in depth on adding detailed error handling to the app, but that's a necessary portion of the user experience that I'll be researching and implementing soon
Adding an Experience tracker that affects a user's chance to catch a Pokemon, dependent on how many Pokemon a user has seen and caught previously
Implementing a more detailed model for the Pokedex, namely by allowing users to track how many different types of Pokemon they've seen, deep dive into the stats of their current Pokemon, sort Pokemon by type, and displaying their progress toward c̶a̶t̶c̶h̶i̶n̶g̶ fetching them all!
Offering multiple user profiles, allowing multiple users' statistics to be tracked simultaneously

As it stands, the application currently has the core functionality that I wanted as a baseline for the project, and is built in a modular way that should allow me to add new features relatively easily. Let's talk about how it works!

On the user's initial page load, an event listener waits for the page's DOM content to load, and then triggers an initial asynchronous function that uses a fetch request in combination with a random number generator to pull a random Pokemon from the PokeAPI. Once the Pokemon's data is returned, a card is generated displaying the Pokemon's name and picture, and a function is called that builds a dynamic color background for the picture based on the type(s) of said Pokemon. Two buttons are generated and appended to the card as well, along with their respective event listeners- one allowing the user to attempt to catch the Pokemon, and another allowing them to run away and try their luck with another random Pokemon.

A wild JSON object appears!

The user's Pokedex is also generated, but unless there is stored JSON data in the local server database, it will remain empty. Let's break the card functionality down a bit.

PokeAPI returns an absolutely huge amount of data for each Pokemon. It's absolutely great for planning out extended features, but the prospect of fetching and then storing all of that data repeatedly is a bit terrifying. To simplify things, the app fetches the data from the server, and then runs it through a handler function that extracts and returns the data necessary for the application. Once the data is returned from the handler, it's sent to a function that generates a boilerplate card, and then populates the card with a name, picture, background colors, and the aforementioned catch and run buttons. A function then clears the existing wild Pokemon card from the DOM container, after which the new card is appended to the DOM.

A word on the background colors on the card pictures- they may look like they're part of the picture linked by the PokeAPI, but they're actually dynamically generated for each card depending on what Pokemon types are listed in the JSON data that the API returns. For Pokemon types, the data returned comes in an array, and isn't limited to a single type, which means that each type in the array has to be accounted for in generating a background. The function to handle this contains an object that stores each possible individual Pokemon type as a key, and the corresponding hexadecimal color (pulled from Bulbapedia using a color picker) as that respective key's value. The function takes the array of types from the API data as an argument, and uses the .map method to build a new array of hexadecimal color codes in place of types. That array is then converted to a string using the .join method, and returned in the form of a CSS property, linear-gradient, that will create a pretty gradient of all of the colors in the array. The function in charge of constructing the Pokemon's card then uses the .style attribute to change the background-image property of the image to the gradient generated by the function. It's a fairly simple function, but I feel like it's one feature that really classed up the look of the application.

At this point, the user has a wild Pokemon displayed on the screen, an empty Pokedex, and two options, to either throw a PokeBall, or to run away. They want to start filling that Pokedex up, but let's start by covering the run away option, in case the Pokemon that was pulled doesn't fit their tastes. The event listener for the run away button simply calls the same function that's automatically called on the application's initial load, repeating the prior steps of generating a random number, using it to fetch a Pokemon from the API, and then creating and displaying a card for that Pokemon. Simple, right?

Now on to the actual point of the app, catching Pokemon. The user sees a Pokemon they like, they smash that Throw A PokeBall button, and... they get an alert message saying that the Pokemon got away! That's because there's a random chance that you'll fail to catch a Pokemon, triggered through a simple function that generates a random number between 0 and 1, and then compares that to a default catch chance. This function was implemented as the first part of the player experience extended feature I mentioned above, and will eventually have another function that tracks experience plugged into it, modifying the catch chance dynamically based on a user's experience level. At the moment, it's just a static value, but it nonetheless means that the user won't catch every Pokemon they toss a PokeBall at.

If they're not caught out by the random number generator, their throw will be successful, and the Pokemon will be caught! Yay! This is where the local server and data persistence goals of the project come in. Once a Pokemon is caught, its respective object is immediately sent to the local server through a POST request. Once that data is stored, we once again loop back to the initial page load function, but this time, some additional functionality built into that function is triggered. On every page refresh, or anytime the initial page load function is called, a GET request is made to the local server. If the local server doesn't have any Pokemon data, then the Pokedex remains empty, and the user will see the same functionality as when they open the page for the first time. However, in this case, we have a Pokemon stored on the local server, and this triggers a function that passes the local server's JSON data to another card creation function. This function builds a card much in the same way as the function mentioned above, but instead of "Throw a PokeBall!" and "Run Away!" buttons, the card has "Rename" and "Release" options. Once the card is constructed, it's appended to the DOM, and any further Pokemon objects stored on the local server are iterated over as well to create a PokeDex showing the user's Pokemon collection.

Alright, so the user now has the Eeveelution of their dreams, but they want to rename them. That functionality is built into the card that was appended to the Pokedex earlier through the "Rename" button. On clicking the button, the user is presented with a pop up window asking for a nickname for their Pokemon. The functionality at this point is a bit wonky, as the local server template I'm working with only allowed Pokemon objects to be accessed via an ID number that was sequentially generated when the Pokemon was POSTed to the server. Because of this, the rename function first GETs the data for every Pokemon in the Pokedex from the local server, and then iterates through them, searching for the object and ID associated with the old name of their Pokemon. That ID is stored, and then used in a PATCH request that references that specific ID, and then updates the corresponding object with the new nickname entered by the user. The name on the respective card is then updated, without having to regenerate the entire Pokedex.

The user has now braved the random number generator, run away from a Pokemon, caught another, renamed them, and now has a Pokemon in their Pokedex that they can show off to the world. Perfect! But let's say they catch a second Pokemon, and the two Pokemon just don't get along. How could they rectify this situation? Easily! The "Release" button!

When the user clicks the "Release" button, similar functionality to the "Rename" button is triggered, starting with all of the Pokemon JSON data from the local server being pulled with a GET request. Once that data is in hand, the function searches for the relevant object's ID, just as described above. Once it has that ID, a DELETE request is sent to the local server to remove that Pokemon from the stored Pokedex. The user is presented with a pop up confirming that the Pokemon has been released, and the relevant card is removed from the Pokedex. Lastly, a function checks if the Pokedex is currently empty, and if it is, updates it with a message instead of leaving it as a blank screen.

That's the basic functionality of the app covered. I'll have a separate blog post covering some of what I learned in greater detail while building this app, but I've already identified some areas that could be improved. First, the application is mostly statically sized. I simply didn't have the time to look deeply into responsive design, and to make the app look good on multiple devices. It's one of the key things I've taken away from this project, and will be one of my focuses going forward. Second, my time for this was 95% devoted to functionality. While my interest mostly lies in the code and not graphic design, this app made me want to learn more about combining function and aesthetics, instead of using generic styles and making it look somewhat acceptable. Front-end design will definitely be another topic I'll be spending time looking into. Third, this entire app was built before our cohort started lessons on context and the "this" keyword, and I can already see multiple opportunities to refactor the code using those lessons. Fourth, and finally, I feel like I need to work more on my understanding of how to best use asynchronous code. I came out of this project feeling like I knew how to make it work, but not like I really deeply understood why it was working, or how I could leverage asynchronicity to improve the performance and user experience of my applications. That'll definitely be a further focus in the weeks ahead.

That wraps up my companion post for my first web application! Check out the repository if you want to read over the code, and if you have any advice, I'm always open to hearing how I can improve. Thanks for reading!

Brief Video Demo
Github Repository

Initial Commit

Lauren Hoock — Sat, 09 Apr 2022 07:03:37 +0000

I was your typical completely insufferable high school kid – the one who had everything completely figured out, seemed to have it all together, was accepted to a great school, had their life planned out to the minute after graduation- you know the type. The kind who, when a friend asks for advice on figuring out what to do with their life, recounts their entire absolutely perfect plan without realizing how just painfully smug they come across as. Plot twist (I bet no one saw that coming), but life absolutely had other plans for me, and little did I know that I literally wouldn’t recognize myself or any of those plans 10 years down the road.

I graduated high school in 2007, and started pursuing a degree in aeronautical engineering at a very prestigious college, with the dream of one day working for NASA. I was absolutely obsessed with all things aviation, and I was completely determined to make a career as an engineer in the aerospace industry. Several years into chasing that dream, medical issues derailed everything, and I was forced to abandon my degree and start dealing with some things that were out of my control. I had to start literally everything over from scratch. With my plans all completely scattered to the wind by what I was dealing with medically, I moved to Colorado to be with my family, started a job at a car dealership (not exactly the work I’d been hoping to do on the Space Shuttle, but BMWs had their redeeming qualities too), and started trying to work out just where to go from there. The short answer to that question was, I had no idea.

I drifted along for the next several years, moving from one aimless job to the next, looking for something to fill the hole in my life that being unable to pursue the career I’d dreamed of in aviation had left. I’ve always been extremely into the technical side of things (hence the aeronautical engineering thing), and as a hobby, I started playing around with Linux, eventually converting my daily driver laptop over to a Debian setup. That necessitated learning some basic coding skills, because you can only use a completely stock Linux setup for so long before the endless Reddit screenshots of custom desktops get to you and you start messing with configuration files. It wasn’t long before the engineering nerd in me started getting more and more into learning just how those files actually worked, and eventually, I found myself, like so many others, searching around for the best programming languages to learn. I ended up on The Odin Project, started working through their web development curriculum, and realized pretty quickly that I was hooked. I spent hundreds of hours working through their lessons and reading blogs about how to get started in software development, and at some point, I realized that I really did want to make a career out of this new and exciting thing that I’d originally gotten myself into as a hobby. The only problem was, I had absolutely no idea what I should know to make that career a reality, and despite being a very self motivated learner, I started to hit a wall.

Image from Thinkful Blog

There’s a great graph that I found early in my coding days about the emotional journey of learning to code. It describes starting out, being excited by this new skill that you’re learning, and then, as you learn more and more, falling into complete despair over feeling like you actually have no idea what you’re doing. I got to that point VERY quickly. I started to doubt myself, and wondered whether software development was something I could actually realistically make happen as a career. Going the self-taught route seemed like such a good idea when I was just dabbling in it, but thinking about getting myself to the point where I could pass a technical interview seemed way too daunting to be realistic. I had hit a point where I didn’t know what I didn’t know, and I started to realize that I needed a structured curriculum to feel like I was adequately prepped for making such a big jump in careers. Luckily, around that time, I was working at Amazon, and flyers started to go up for Flatiron School’s Software Development course. I applied, interviewed, had a small nervous breakdown in the week between the interview and the acceptance decision, and only squeaked a little bit when I got the email that I’d been admitted. The instructors have been great so far, and the courses, while they’re a lot to process, are so far exactly what I needed, and they’re absolutely delivering on the overall guidance that I felt I personally needed in place of the free options out there. I’m only a few weeks in, and I’m sure there are a lot of sleepless nights ahead of trying to balance projects and my full time job, but I’m extremely excited about what the future might hold, and can’t wait to get further into the program!