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!
Top comments (0)