My first JavaScript project is done. At least in its first final draft, that is. I chose a playlist curator concept wherein anyone viewing the application in the browser is able to view running lists of songs, organized by their genre into playlists. Anyone viewing the application may also add songs to any of the lists as well as delete them. This post is going to provide an overview of my favorite concept in Javascript so far: event listeners.
In my playlist application, we have a single-page app that displays a full list of playlists that have been saved to the database (a Rails API I created on PostgreSQL for deployment reasons later on). A greeting and the list of playlists are all a viewer can see at first glance. However, each playlist is instantiated with an event listener waiting for a "click." This click triggers another function and that function carries out a process and so on. Let's take a look:
Here, right in the playlist constructor function, I am assigning an event listener, by way of a callback function. Callback functions have also proven very useful for the technical reasons of course, but particularly for me they assist with organization. So, moving down to the callback function, I am displaying the list of each playlist's respective songs using the .filter() method and also populating the form for a new song to be added.
Since the song is being added within its respective playlist, it was important for me to determine how to build this association on instantiation of a new song. The callback function I mentioned previously is the gateway to the form for the new song. So, before going further, it is important to note that the form I have created for a new song lives inside of a static function with a few main purposes: the first purpose being to render the form which also begins to handle the submitting of the information, and two event listeners, one for the click on submit, and the other for a click on the inverse functionality, which is deleting a song entry.
So now, with all of this, we have the data being displayed, a form for a new entry being rendered, and the different kinds of clicks being handled. Here is what is happening behind the "submit" event handler:
Here is where the playlist-song association is being made without any user intervention. With some DOM manipulation, I was able to locate the elements necessary for assigning the attributes to a newly entered song. With this information, a song can be added to a playlist successfully and is able to be viewed by other users, without having to refresh the page. On "submit," the song is attached to the DOM under its respective playlist as well as an associated "delete" button.
What is also happening on the frontend is the configuration of this newly-entered object. The method I named createSong() takes on this challenge. I pass through the attributes collected from the form (which I saved as variables), and then a fetch request is required to communicate with the database, ensure the data entered is valid and meets parameter requisites, and save the appropriate data. The fetch request in createSong() (my create function) is rather simple in that the frontend signals the back, instantiates the new object with the provided information, and provided all goes according to plan, carries out any additional functionality appropriate for a fetch request, such as rendering the information and reseting the data in the form.
This process is highly reusable. I have found that being able to navigate callback functions holds me much more accountable for organization in my own application. Understanding how these work and the asynchronous potential and behavior in JavaScript is something I am still broadening my understanding of, but methods like preventDefault() and stopPropagation() have also been helpful along the way.
Find my repositories here:
frontend:https://github.com/katiekatiekatiee/playlist-frontend
backend: https://github.com/katiekatiekatiee/playlist-backend
Top comments (0)