My First React Project
Tags: discuss, react, es6, purecss
Published: 2023-09-28 07:16:00

---
title: My First React Project
published: true
description: My revamped music website in React-native
tags: discuss, ReactJS, ES6, pureCSS
# cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/g0tlyp206mz71oqi8rh2.png
# Use a ratio of 100:42 for best results.
# published_at: 2023-09-28 05:38 +0000
---

Though I've been a web developer for many years, the job I've had for the last few years doesn't challenge my programming skills much so I have been spending evenings trying to keep my front end dev chops up. Earlier this year I decided to try my hand at React for the first time...and I found that I love it. After a few small experiments and tutorials (from Brad Traversy's YouTube channel) I tried my hand at building a full-fledged, functional website. And it just so happened that my PHP/SQL-based song website (of songs I've written) was in dire need of updating - so I got to be the designer, developer and the client. The result is here: https://www.chrishowardsongs.com/. As an additional challenge I wanted to make this site without any images, just pure CSS, icons, fonts and using vanilla (ES6) JavaScript instead of library dependencies like jQuery. The code lives here: https://github.com/thestillfracture/ChrisHowardSongs/tree/master.

Of course I tried to avoid spaghetti code and to stay DRY but I'm certain that I fell short on those in places so I'll be refactoring this for sure. One of the bigger challenges I had was dealing with the event handler on the songs. Specifically, when the user hits the play button an audio object is created. On this object an onended event is set because when the song ends the player needs to consider things such as whether the "PlayAll" button is on, and if it is then it needs to decide what the next song in the list is. But that is complicated by the fact that in the time between setting the onended event and the time that it executes the user may have changed the state. For example, he/she may have changed the "PlayAll" status, filtered in our out songs (including the one playing) or sorted so that what was the next song when the current song began playing is no longer the next song. 

I ended up relying on useRef to solve this but in retrospect I think moving away from the event handler directly triggering the logic would have been the true React method. In my imagination it seems I could just manage the state of whether a song (regardless of the song) was playing via a useState hook set as a boolean - set as true if a song is playing/paused and false when it ends. Changing this state would be the only thing the onended event would need to do. Tied to that useState as its callback I'd leverage useEffect to check the state of the other dependencies - for example, what the next song is if "PlayAll" is on. If anyone has advice on whether that would work and whether it's the "React way", or if a different method is more efficient, feel free to leave it in the comments. 

If my idea is a viable solution I think it would clean up a LOT of the code. However it gets refactored I expect to deal with that functionality at some point, but right now I'm just happy that all the client's (me) demands have been met and that it appears the site is working as intended.