DEV Community: Julie Evans

Fetching in Tandem

Julie Evans — Wed, 31 Aug 2022 21:36:48 +0000

To start off let me first explain what I mean by fetching in tandem. Fetching is a process to access the data from a database or API with a fetch request. More about fetching can be found here. To have this process run in duality is what I mean for it to be in tandem. That is if I make a fetch request that requires either the data from another fetch request or at least the process to have run. In this particular case, I wanted to have a fetch request nested inside another, so that it would run right after the other within a single motion. So it’s not exactly simultaneous but in my case I had it run in a single handler function, so I consider that to be a single motion and thus in tandem.

Now to explain what I had going on in this example and how I got to that point, I will first explain my setup. My database was set up with a many-to-many relationship pertaining to three tables. These tables were a Photos table, a Tags table, and a PhotoTags table. The PhotoTags table is the join-table connecting the other two, with a foreign key column for each of the other respective tables.

For some reference here is what my schema looks like:

db/schema.rb

create_table "photos", force: :cascade do |t|
  t.string "image"
  t.text "description"
  t.integer "user_id"
end

create_table "tags", force: :cascade do |t|
  t.string "name"
end

create_table "photo_tags", force: :cascade do |t|
  t.integer "photo_id"
  t.integer "tag_id"
end

Going forward I will explain what I had going on. To start with this example involves a form page set up to add photos to the database. This form has three inputs: Image, Description, and Tags. Image is for the image URL. Description and Tags are optional. Description is for if the user wants to add some descriptive text to the photo. Tags is for adding and selecting tags from the database in order to have them attached to the photo. Adding tags to the database is handled by an onKeyDown event handler function, but more importantly, attaching those tags is handled by an onChange event handler function for selecting and then a POST fetch request for attaching them to the photo.

client/AddPhoto.js: onChange

onChange={(event, newValue) => {
  tags.filter( tag => {
    newValue.length > 0 ? (
      newValue.filter( value => {
         if(value === tag.name) {
          setSelectedTags([...selectedTags, tag])
        }
      } )
    ) : (
      setSelectedTags([])
    )
  } )
}}

This is my onChange handler for the tags' form input. Simply put, I check to see if there are any tags in the input and add them to a state variable called selectedTags. I checked if there was a tag added by seeing if the newValue prop was empty or not. I then matched the newValue with the tags from the database. Both tags and newValue are arrays, but the tags array is from the database and thus has id's where as the newValue array only has the name value of the tag. I match these two arrays by filtering through both. I do this in order to grab the tag from the database that has the same name as the tag in the newValue array. Basically, I'm grabbing the tag with its id from the array displayed on the DOM. If they do match the comparison I set them to the selectedTags array using useState. This way the selectedTags array matches what the user sees on the DOM but also contains the id's to help later with adding the association to the photo via the photo_tags Join table.

The harder part is adding that association, taking the tags that have been selected and attaching them to the photo. To do this requires a POST fetch request to the photo_tags Join table, for each tag to be attached to the photo. But first, we need to have photo to add these to. That isn't really a problem, except that the photo needs to be in the database and have an id. This is because the association between the photos and tags in the Join table are reliant on id's as its foreign keys (look to the schema for clarification on this). This isn't a problem either, because I just need to run a POST fetch request to add the photo to the database and then run the POST fetch request to the Join table to attach the tags. The problem here lies in the fact that this is one form with one submit button. So in order to have the tags associated with the photo as well as the photo to be added to the database upon clicking the single submit button I need to run both POST fetch requests almost simultaneously. I do this by running the two fetch requests right after each other inside the submit handler function. This way they both initiate upon the submit button click, but I also control them so that the photo's fetch request is run and with the return of the data from its completion to then run the photo_tag's fetch request with that data.

Here is what my submit handler function looks like:

client/AddPhoto.js: handleSubmit

function handleSubmit(event) {
 event.preventDefault()

 fetch("/photos", {
   method: "POST",
   headers: {
     "Content-Type": "application/json"
   },
   body: JSON.stringify(formData)
 })
 .then((r) => {
   if (r.ok) {
     r.json().then((photo) => {
       if(selectedTags.length > 0) {
         selectedTags.map( tag => {
           fetch("/photo_tags", {
             method: "POST",
             headers: {
               "Content-Type": "application/json"
             },
             body: JSON.stringify({ photo_id: photo.id, tag_id: tag.id })
           })
           .then((r) => {
             if (r.ok) {
               r.json().then((photoTag) => {
                 console.log(photoTag)
               })
             }
             else {
               r.json().then((err) => setErrors(err.errors))
             }
           })
         })
       }
     }).then(() => {
       history.push(`/users/${currentUser.id}`)
     })
   } else {
     r.json().then((err) => {
       setErrors(err.errors.map((error) => error.toLowerCase()))
     })
   }
 })
}

The formData here is an object that contains the URL of the image and the description for the photo. These are added via useState from the other form inputs. I have errors set from both fetch requests, but since the photo_tag fetch request can't run without the photo's id or the tags' id's it never gets to that point. I also console logged the data from the photo_tag fetch request to confirm everything's working properly. I set the photo_tag fetch request to run after the photo fetch request by nesting it inside of its response, and it also will only run if tags have been selected (since adding tags to a photo is optional). If there are selectedTags it will iterate through them and run the photo_tag fetch request for each tag. Once all of the fetch requests have run it will then redirect to the user's page I have set up with the id of the user that is logged in (aka. the currentUser). On a side note, the addition of photos and tags also requires a user to be logged in. The photo table also has a user_id foreign key, but that is handled in the controller, here:

app/controllers/photos_controller.rb: create

def create
  photo = @current_user.photos.create!(photo_params)
  render json: photo, status: :created
end

In conclusion, it is not that I have fetches running simultaneously, but that I have them run one after the other by nesting them and having them within a single action (submit handler initiated upon button click action).

Creating a “Follow” button: from Rails to React using Self-Join

Julie Evans — Wed, 15 Jun 2022 23:02:04 +0000

For the first time, I attempted creating a button that a user could click to follow or unfollow another user.

Database and Self-Join

First of all, the database is set up as a many-to-many relationship. But, it is also self-referential, otherwise known as a self-join. This means that the data in the database uses another table (in this case “Friendship”) to reference a table with itself (in this case “User”). More on this later…

Here is the schema and a diagram to demonstrate these database tables:

// db/schema.rb

  create_table "friendships", force: :cascade do |t|
    t.datetime "created_at", null: false
    t.datetime "updated_at", null: false
    t.integer "follower_id"
    t.integer "followee_id"
  end

  create_table "users", force: :cascade do |t|
    t.string "username"
    t.string "password_digest"
    t.datetime "created_at", null: false
    t.datetime "updated_at", null: false
  end

After reading this and this, in addition to the Rails guide, I got an understanding of Self-Join. In the case I used it, based on this, the database needs to be set up just like a many-to-many relationship. It needs a separate table to act as a go-between and store the action’s information. The only difference would be that instead of this separate table in between two other tables, it would have one other table referencing itself.

User >- Friendship -< User
(the User here is the same table - just the connection would look like this)

instead of something like this…

User >- Like -< Post

Another way to look at it is that the Friendship table holds the information pertaining to the “follow” action in this case, and that info contains the id of the user that initiated the action as a foreign key as well as the id of the user the action was initiated upon also as a foreign key. It has two user ids, one in the follower column and the other in the followee column.

The Friendship database table would look something like this:

follower_id	followee_id
1	2
2	1

NOTE: For clarification, the first row has the user with the id of 1 following the user with the id of 2, and the second row has the user with the id of 1 being followed by the user with the id of 2. Also, the ids of the users are the primary keys from the User table. On a side note, this table would also have another column for the primary key of the relationship or row in the Friendship table.

Rails Backend

On the back-end of things, there are primarily two things, the models and the controllers concerning this Friendship table as well as the User table.

The most important part of this whole thing lies in the models, especially the User model. Both of these models set up the connections for the tables in the database. The Friendship model essentially allows the follower and followee to be present and that they come from the User model.

// app/models/friendship.rb

class Friendship < ApplicationRecord
  belongs_to :follower, class_name: "User"
  belongs_to :followee, class_name: "User"
end

The User model is a bit more complicated. It needs the send the follower and followee to the Friendship model. In order to do that it needs to define them.

// app/models/user.rb

class User < ApplicationRecord
  has_many :followed_users, foreign_key: :follower_id, class_name: "Friendship"
  has_many :followees, through: :followed_users
  has_many :following_users, foreign_key: :followee_id, class_name: "Friendship"
  has_many :followers, through: :following_users
end

Here the followers and followees are the same as the follower and followee from the Friendship model. They are defined using has_many, through:. The key that it is through here is from another has_many which is defined using foreign_key:. This foreign key is the key used to define the column in the Friendship table from the database, which were follower_id and followee_id. These are from the Friendship table and are the foreign keys that are defined clearly in the model here with the has_many statement. The has_many, through: statements are simply to allow access to these foreign keys in the Friendship model under new labels for clarity.

The controllers define the actions of the models. Here the Friendship controller is the more important one. It defines the adding and deleting of data to the Friendship table, or in other words the creation and deletion of new rows in the table.

// app/controllers/friendships_controller.rb

class FriendshipsController < ApplicationController

  def create
    friendship = Friendship.create!(friendship_params)
    render json: friendship, status: :created
  end

  def destroy
    friendship = Friendship.find_by!({follower_id: session[:user_id], followee_id: params[:id]})
    friendship.destroy
    head :no_content
  end

  private

  def friendship_params
    params.permit(:id, :followee_id, :follower_id)
  end

end

In the methods defined here, the Friendship class must be used to define the action. If the action is defined using the User class (ex. User.followers.create!) the action of this method will most likely trigger the creation or deletion of new users, rather than the creation or deletion of a relationship between them (aka. a following or unfollowing).

NOTE: Using User.followers or User.followees will work in the console will the shovel method. Look at this for more information or examples on this.

Also, the parameters or params used are the foreign keys directly from the table rather than the new labels from the model. In addition, the params used for the delete method use the user id saved in the session since this action can only be performed when there is a user logged in anyways, and the other params are from the fetch request route that has the :id of the user being followed. The delete here grabs both of these in an object as the follower_id and followee_id respectively. This is so the find_by will target the whole row in the Friendship table that has the exact same information.

The creation method is similar, except that this object is defined in the body of the fetch request instead.

React Frontend

// client/src/components/FollowBtn.js

function FollowBtn({currentUser, user, onError, onFollow, isFollowing}) {

  function handleFollow(e) {
    const following = currentUser ? {followee_id: user.id, follower_id: currentUser.id} : null

    isFollowing ? (
      fetch(`/friendships/${user.id}`, {
        method: "DELETE",
        headers: {
          "Content-Type": "application/json",
        }
      })
        .then((r) => {
          onFollow(false)
        })
      ) : (
        fetch("/friendships", {
          method: "POST",
          headers: {
            "Content-Type": "application/json",
          },
          body: JSON.stringify(following)
        })
          .then((r) => {
            if (r.ok) {
              r.json().then((data) => {
                onFollow(true)
              })
            } else {
              r.json().then((err) => onError(err.errors))
            }
          })
      )
  }

  return(
    <>
      <button onClick={handleFollow} className="button">{isFollowing ? "Unfollow" : "Follow"}</button>
    </>
  )
}

export default FollowBtn;

This is a lot, but this is the component for the Follow button that includes the function on the front-end that handles the clicking of the button.

It takes the currentUser and user variables from its parent. The currentUser is the variable fetched from the user saved in the session, in other words, whoever is logged in on the browser. The user is from the data that the button is set on, which also makes it whoever the follow is attached to or the one to be followed. If there is a current user or a user logged in, the following variable is an object containing the id of the user as the followee_id and the id of the current user as the follower_id.

The following variable is the object for the body of the fetch request. The isFollowing variable is a boolean that checks to see if the current user is already following this user. If they are already following them, then the click on the button will go to the DELETE fetch request, otherwise it will go to the POST fetch request. The DELETE fetch sends the request to the /:id/unfollow route I have defined, but this requires the id of the user that this button is attached to. The POST fetch does not require the id because it is in the body of the request.

The onFollow sends the data of these actions to the parent, which controls the isFollowing variable as well as whether the button displays “FOLLOW” or “UNFOLLOW”. The onError similarly sends data to the parent, but it only sends the /errors/ if there are any. This was simply for display convenience, because it looked better in the parent rather than inside the button itself 😅.

For more references:

These are some articles I found on this topic, or at least a part of or similar topics. Mostly revolving around self-join (since this was uncharted territory for me).

CSS Components

Julie Evans — Sat, 26 Mar 2022 00:50:18 +0000

When I was first introduced to React and it’s components, I fell in love with them. I couldn't believe I didn't know about them or even anything like them until that point. Also to note, I'm an avid folders user in organizing my computer content, especially photos. So its understandable how excited I got when I found I could do the same for my code.

In case you don't know what components are... A good explanation is here on React docs on Components and Props. For me, I would describe components as good way to compartmentalize your code. I like to imagine components as Lego blocks or comparable to folders. Like building blocks or parts to use, reuse, and build off of as well as to organize. Although I think that the construction and utilization of components is nearly identical to that of functions.

One day, I thought to myself, “why don't I apply components to my CSS.” Although I was utilizing the components in React to reuse and compartmentalize my code, I still had an insanely long and convoluted CSS file. So, when I had this idea I thought I’d try it out with my next project. Which, considering how much I liked components and organizing stuff, I surprised myself with that it took me this long.

Since I was styling based on parts, my CSS file would be in segments based on those. Although my CSS file was somewhat organized, but despite this, I can bet that I am probably the only one that could understand it, and see where things were and what was going on.

To say the least, applying components to CSS was a great success. Not only could I compartmentalize and organize my styles, but also easily know which React components they were connected to because I also based my CSS components off of my React components.

It helped me the most where I styled a form. The project I tried using Css components on had four different submission forms and three different styles of those forms. I reused the CSS just as I would have for React components.

I started by creating one CSS component as a generalized or base style, which I mainly used to keep colors consistent, set direction flow, and to set the minimum size. After that I made new CSS components for each other different type of form. I had one form be a larger version and another be horizontal instead of vertical.

Since I had the generalized form CSS component, I didn't have to do much for the third type, where as the other 2 simply played off of the generalized style. I only changed the parts that needed to be different for the other two types of form styles, and everything else stayed the same which stayed in the base styles component. Not only did this all simplify my CSS code, but it also made it easier to look at and compare.

Although I could talk in more detail about this and how good it is, I will stop here. The main take away from all of this is that compartmentalizing code makes looking at and using code so much better, especially for reuse and comparison, and the best part is that its even better with CSS.

One last thing to note, I’ve referred to these as CSS components but it might be better to describe them closer to separated CSS files or folder-like CSS segments. React components are individual files that act like functions, but the CSS components here are individual files of ordinary CSS that I organized to match my React components. So I call them components based on how I synchronized them with my React components rather than by pure definition.

Communication between Sinatra Routes and React Fetch Requests

Julie Evans — Sat, 26 Mar 2022 00:48:57 +0000

What are Routes and Requests anyways?

For those who don’t know what Sinatra routes or React fetch requests are, I’ll give a brief rundown. Sinatra routes are the communication between you and the database, and function similarly to URLs. React fetch requests are a way for React to communicate with a backend like an API or database, and in this case using the Sinatra routes as a medium or mediator.

What is this all about?

Although this title is pretty long, it sums up all that I plan to say. First I'd like to say that this was an issue I came across, and it took me awhile to figure out what the problem was. I struggled with it because I had assumed my mistake was on my frontend, like a typo or something. I thought this because of how complicated the part I was working on was. It was my EDIT button, and I had the data traveling through several components back and forth, as well as through different functions and nested if statements.

To figure out that it was not my frontend that had the error, I turned off the data being sent so that I was left with just the components. I went through each step that the data would travel through, and checked what it was with a console.log. In doing this I saw that it was not my complicated traveling or nested if statements. The problem lied in the data itself, or to be more accurate what happened to the data as it travel.

While I logged the data at each step, I noticed a discrepancy. The data I sent to be edited and the data sent back after being edited were different. I was a slight difference and a small mistake on my part, so I simply didn't notice it. In fact, I hadn't noticed it until it was breaking my code.

The mistake was in my databases, or more specifically my routes. I had my Sinatra routes looking like this:

patch "/items/:id" do
    item = Item.find(params[:id])
    item.update(
        name: params[:name],
        price: params[:price],
        priority: params[:priority],
        category: params[:category],
        balance_id: params[:balance_id]
    )
    item.to_json
end

With the route like this, the data received afterwards would look like this:

{
    name: “placeholder name”,
    price: 0.00,
    priority: 1,
    category: “placeholder category”,
    balance_id: 1
}

The problem was that my data being sent to it looked like this:

{
    name: “placeholder name”,
    price: 0.00,
    priority: 1,
    category: “placeholder category”,
    balance: {
        id: 1,
        name: “placeholder name”,
        amount: 0.00
    }
}

So what was happening was that the data I sent to be edited had a "balance" key, whereas the edited data I got back had a "balance_id". My code was breaking because when I tried to render the new data it would try to read the keys of the object under the "balance" key, but it no longer existed.

It all had to do with what my Sinatra routes gave and received, but my databases and how my data was connected between them also played a part. To explain I'll first explain what my databases and data was doing on the backend. To start the data in my databases and how they were connected could be best shown with this diagram:

I had a one-to-many relationship between my balances and items databases, with a foreign id connecting them. This was all fine and good up until I was writing my routes. Having my routes have the "balance_id" key was not the problem, since that was the connecting factor. Because I was working with items I needed the keys to match the columns on the database, which I did. The problem was that my other routes had the data shown differently that how it was received. I needed the data received to be consistent throughout all of my routes.

The fix was simple, since how I was sending my data was not the issue. I simply needed to add the same statement specifying how I want the data to look, or in other words what the data received was. Which was the "only" and "includes" I had added to the other routes, but had forgotten to add here. The fixed version of my Sinatra route looked liked this:

patch "/items/:id" do
    item = Item.find(params[:id])
    item.update(
        name: params[:name],
        price: params[:price],
        priority: params[:priority],
        category: params[:category],
        balance_id: params[:balance_id]
    )
    item.to_json(only: [:id, :name, :price, :priority, :category], include: :balance)
end

Although the data in essence was the same, how it looked and communicated between the frontend and backend was different. I found this subtle difference fascinating, and could apparently make-or-break my code. What was even more interesting was that my fetch request in React looked the same as the database, the same as the routes. It looked like this:

const formData = {
    name: itemName,
    price: itemPrice,
    priority: itemPriority,
    category: itemCategory,
    balance_id: balanceId,
}

fetch(`http://localhost:9292/items/${id}`, {
    method: "PATCH",
    headers: {
        "Content-Type": "application/json"
    },
    body: JSON.stringify(formData)
})
    .then(res => res.json())
    .then(data => onEditSubmit(data))

The "formData" here in the fetch request and the part inside of the update in the route are exactly the same. They need to be identical in order to work with database, where they need to match the columns. These parts need to be identical to function. But since I had the balances database attached to the items and an add on, neither the data nor the databases changed, simply the way it looked afterwards.

Both the fetch requests and routes communicate with each other and the databases the same way. I simply told it to show me the balance connect to the item instead of the foreign id, which was all in the only and includes attached to the "to_json" on the routes. The "only part specified what keys to display. And the "includes" told it to include the whole balance (instance) connected, since I could do that with how my databases were set up. The fetch request on the other end communicates with the databases with the routes as mediators, so without specifying what to display with these "only" and "includes" statements the data would look identical to the default or simply the database itself.

So the takeaway is that the data sent needs to be identical regardless if it is in the route, fetch request, or the database. The only thing is that if you specify how the data received looks, you must be consistent.

Reflecting on React

Julie Evans — Sun, 06 Feb 2022 23:13:39 +0000

During this past month or so I learned how to utilize React. Although I only learned the basics and can only make good use of two hooks, I can implement them in ways to make them work. I can also utilize JSX and React’s hooks to implement the same functionality as if I were using JavaScript. The primary different is the ease of use and the lack of complexity in the appearance. My favorite aspect of using JSX instead of simply using JavaScript, is that JSX looks similar to typical HTML and makes it easier to see what is going on in the code. Plus I can implement the JavaScript functionality directly into the same code I use for rendering. So for me it’s like looking at HTML that functions as JavaScript, which is both beautiful and easier to use, at least it is for me.

Other than how much better I like JSX in comparison to typical JavaScript, is the use of React, which is super great. I can use it to render the HTML by using JSX and use its hooks to store information and the like and minimize unnecessary extra loading or rendering. I really like using the useState hook, because it not only makes my life easier with it storing information, it is also really easy to use. I previously used simple variables in JavaScript to achieve the same functionality, but it was messy and complicated, and it just barely helped me to achieve the functionality I wanted. Looking back I probably overcomplicated my situation more than necessary, but regardless using useState is much kinder to me. Using the useState hook not only is simple to use, but is also not a strain to look at and can be used without much complexity.

In addition to the useState hook I learned to utilize the useEffect hook, which I primarily used in tandem with useState. This was to fetch data from an API or JSON file and store the data within a variable declared with useState and then be able to utilize that data with ease without extraneous fetch requests. The useEffect hook has other neat uses and side-effects that can be implemented here and there, but I found its use with fetch requests was very helpful and made things easier to look at and more organized for me to use. If you can find at least one use for it and be able to utilize it, then I think that is enough to get by.

I primarily used the useState and useEffect hooks, but I also learned about routing with “react-router-dom” and using its hooks. It’s extremely helpful and quicker using this routing, and the uses it has in addition to simple links make creating navigation bars and alternating page content super simple. In addition to React’s hooks and features that can be accessed and used by simply importing them, there are other features and the like that are just as easy to get a hold of and use. Rather than trying to learn how to accomplish something and straining to figure out the ins and out of a certain feature, you can simply import the feature itself. Working with features and components this way makes creating content and features so much simpler and quicker. Utilizing React and similar features is the coolest thing I have come across so far, and using it through JSX is a joy to look at and use. The combination of the two is a wonder to behold and an ease to use.

currentTarget vs. target

Julie Evans — Fri, 31 Dec 2021 02:49:11 +0000

One of the things I have learned recently is the difference between currentTarget and target. I learned this by experimentation, so there is probably a better and more explicit explanation out there. But with my newbie knowledge, I am going to explain the difference of these two based on what I learned. On a side note, I have not looked up any information pertaining to this topic. This is solely based on what I found out through my trial and error.

As I was working on a project I ran into a certain snag. Although I ran into a couple of snags along the way, the most significant one for me was the one concerning currentTarget. Clicking one of the buttons activated two click event functions. One for the button itself, the other for the whole object that the button was a part of. I couldn’t figure out what was the problem at first, but then I realized I had used currentTarget instead of target to identify the event target for the click events. Overall its not much of an issue, but since I had two click events that were stacked and part of the same element, it became a problem.

currentTarget was not something I had used previously. I used it because it seamed to simplified identifying the whole object that was being clicked on, rather that trying to find the right parentNode. currentTarget runs more off of the element that the event listener is placed on, whereas target is the element on the DOM that is directly being clicked on. Essentially, target identifies the specific element or tag being clicked on, and currentTarget identifies the general item being clicked on.

Since I had div tags upon div tags in each card or object, I decided to try using currentTarget instead. I wanted the click function to work on the whole card, rather than its individual contents or having to stack several parentNodes. It all worked smoothly until I complicated matters with adding the button inside the card with its own event listener. The button tag as well as its event listener were both inside of the card itself, so the event listener on the whole card would run both, if the button inside was clicked. Moving the button’s event listener outside of the card might have fixed it, but I decided for a more fool-proof method. I decided to add an if statement on my function that would run only if the target of the click was the card, or had the class of “card” to be more specific. I had the if statement use target, but still used currentTarget on the function being called inside. This made the event handler still function the same way as before the addition of the button, but clarified the target of the click.

I ended up adapting this clarification statement to all of my event handlers for this project, to ensure the function I wanted to happen would only work on the corelating targets. I had a class of "checkbox" or my button, and a class of "card" on the whole card itself. I used the contains within the if statement, for the clarification of the click target. The event handler for the card click turned out to look like this:

function handleClick(e) {
  let id = e.currentTarget.querySelector(".checkbox").id
  if(e.target.parentNode.classList.contains("card")) { // checks if click target is card not checkbox
    getDetail(id)
  }
}

Studio Ghibli Watch List

Julie Evans — Thu, 30 Dec 2021 22:54:22 +0000

What can it do?

I made a web application using the Studio Ghibli API. It is a culmination of everything I have learned up to this point in time. I made it with the intended purpose of a watch list, so that the user could mark the Studio Ghibli films that they have watched. The list of films are on the left side, and a more detailed view of a single film on the right. The user can click on a film from the list on the left and have it show on the right with more details, as well as highlight the film on the list that was clicked with a selected view. Both the list and the detailed view have checkbox buttons that correlate to the watched value, so if the user clicks the button the watched value of that specific film with change, from unwatched to watched or vise versa. This action is synced to the film itself, so it doesn't matter if the click has been made on the list or the detail, it will be the same. There is also a filter above the list where the user can filter the list view by whether the film has been marked as watched, as well as which ones were not marked as watched. There are also filters for each of the directors, and for all of the films with no filter active. On a side note, these filters do not stack. The currently active filter will show inside of the filter bar, so the user can always see and know which filter is in use.

How does it do this?

Almost all of the functionality of this web application lies in the JavaScript, the rest is CSS. The parts from the CSS that I like best are the button hovering that inverts the button color and changes the cursor, and the combination of the media queries and displays to have the contents adjust to the screen size.

The initial functionality of this web application are in the fetch requests to the API, which I placed inside of there own functions and called another function with the fetched data to append that data to the DOM. I have two of these fetch requests one for the list and one using an id for the detail, both with they're respective rendering functions. The fetch request functions and rendering functions work in tandem to have the information show on the DOM. I have an extra function which utilizes a while loop to remove the detail's information from the DOM to make room for new information, for when a different film is selected and adds that new information. It acts as a reset for the detailed view.

I have another fetch request within both of the rendering functions, which is to the JSON file. It checks the value of watched from the stored data, and changes the checkbox accordingly. This way the checkbox appears either checked or unchecked based on the stored data upon the initial appending to the DOM. The only other fetch request is another to the JSON file, which this request is in a function that is called when a click event is triggered. It changes the watched value and updates it on the stored data of the JSON file. The click event triggered is a little complicated. The event listener is on the checkbox button and calls the function dubbed handleCheck. The first thing that this function does is it identifies the checkbox buttons of the list on the left and the detail on the right. Since there are multiple checkboxes on the list, it turns them into an iterable array. Then if the currentTarget of the click event is the checkbox button or contains the class of "checkbox" it will call the function with the fetch request to update the JSON file. It then iterates through the array of checkboxes from the list and if the id of the checkboxes match then it change the CSS to make the button appear checked or unchecked. Each of the checkboxes have the id of the film from the API attached as the id, and iterating through the array checks the ids that are already on the DOM so the CSS can change what is already appended to the DOM. The rest of the handleCheck function checks if the id of the list's checkbox matches the detail's checkbox, and syncs the change in CSS if they do. I also ended up adding the "contains class" if statement to all of my event handlers to clarify the intended target of the click event, so that the functionality would only be applied where its intended in a more fool-proof way. All of this turned out to look like this:

function handleCheck(e) {
  const detailCheck = document.querySelector("#detail-container").querySelector(".checkbox")
  const cardChecks = document.querySelector("#cards-container").querySelectorAll(".checkbox")
  const cardChecksArray = [...cardChecks]
  const detailCheckedBtn = detailCheck.querySelector("button")

  if(e.currentTarget.classList.contains("checkbox")) { // checks if click target is checkbox
    updateWatched(e.currentTarget.id)
    cardChecksArray.forEach(cardCheck => {
      if(e.currentTarget.id === cardCheck.id) { // matches click target and list to check of correct checkbox
        if(checked === true) {
          e.currentTarget.querySelector("button").id = "checked"
        }
        else {
          e.currentTarget.querySelector("button").id = ""
        }
        if(cardCheck.id === detailCheck.id) { // syncs check of card and detail
          if(checked === true) {
            cardCheck.querySelector("button").id = "checked"
            detailCheckedBtn.id = "checked"
          }
          else {
            cardCheck.querySelector("button").id = ""
            detailCheckedBtn.id = ""
          }
        }
      }
    })
  }
}

Just like the handleCheck function the handleFilter function is also a little bit complicated because quite a few things go on inside. Although instead of nested if statements like the handleCheck function, the handleFilter function has five else ifs, three of which have a nested if statement. Each of the else ifs act as separate functionality based on what is the desired filter.

The first thing this function does is make an array of from the list just like in the handleCheck function. Then it acquires the id of the click target to make sure it is the filter being clicked on, and if it is it displays the dropdown menu. Then on further clicks the function checks the inner text of the clicked target and displays or hides the content based on that text. Which it also identifies the content to display or hide by iterating through all of the cards on the DOM. It also displays the targeted filter within the filter bar, so than what is currently being filtered is visible. All this is excluding “Director” since it simply a label and not a button, and has no functionality other than hovering over in order to display the dropdown menu. All of the functionality within handleFilter are click events to show and hide items.

I had initially wanted to use select and option tags for the filter, but since I wanted a nested dropdown of directors I could not get the result I wanted. I then switched it to be a ul, where I could not only have the functionality I wanted but also more easily customize its appearance. Since the functionality lies in the JavaScript, regardless of what tags are used the functionality remains the same, only the application of it an its appearance differ.

The only other click event for this web application is the one on the list of films itself, which displays the same film in the more detailed view on the right side. Outside of this function, which is only called upon a click event, is another function that runs to match the detail and card, and makes the card appear selected if they are the same. This function is called inside the rendering detail function to more easily acquire the information from the detail as well as reacquiring it once the detail is refreshed.

Improvements...

There are a few things I think could be improved upon, but cannot with my current knowledge and abilities. The first being that the selected appearance of the list's film doesn't always show upon the initial load-up, but it works fine with the click event. The other things I disliked where that I had fetch requests inside the rendering functions, rather than in their own separate functions, but I couldn't get it to work the way I wanted otherwise. And for some reason my query selectors wouldn't work in the global scope. I also wish that I could improve its load speed and efficiency, but I currently don't know how to do that while keeping the same functionality.

About Me

Julie Evans — Sun, 24 Oct 2021 16:06:09 +0000

Hello, my name is Julie.

I want to start by introducing myself and why I started my journey into the tech world. To start off with, I am a nerd, like most in this industry. My whole family are nerds, so I come by it honestly, although my family has many different types of nerds and I would be the first to get into programming. I'm from Texas, and my motto is "Go big, or go home." My motto may be a little bit of an ultimatum, but it's what propels me to continue moving forward and succeed. I have another saying that I also use, but not as much, which is "It doesn't hurt to try." I get motivation here as well, because it can be daunting when stepping into uncharted territory, but what's important is trying first?

I began learning code when I was in high school. I took a class called "Web Design" where I learned the basics of HTML and CSS. I enjoyed that class so much. I was always one or more steps ahead of the pace the class was set at, and I had many pet-projects on the side where I played around with the things I learned. I seemed to be the most enthusiastic one out of my class, to the point where I was the teacher's pet. I felt a little alone despite being in a class of 30. The rest of the class seemed to treat the assignments begrudgingly, while I was a glutton who wanted to learn as much as possible. At the time there wasn't a class after which to continue my education in coding, so I put it aside and moved on.

After which, I graduated High School and went on to College. I ended up focusing on learning Linguistics, Anthropology, and Japanese. I had enjoyed all of the classes and topics I learned about in College, but I had completely forgotten about coding and how much I had enjoyed learning it. It wasn't until after I had graduated and was trying to find my calling, with little success, that it came like an epiphany. A spark of a moment that came out of nowhere, I remembered about coding and my love for it. I felt a little disappointed that I had forgotten so completely about something I enjoyed so much. I also felt excited because my gut was telling me that this might be it, the thing I had been searching for all these years, what I wanted to invest myself in and pursue as my career.

Now that I have graduated from College and working towards making my career, I thought that now was the opportune moment to try to get back into coding and to go into programming. It felt like fate, and I went with my gut decision to go for it. I haven't had a single important life decision where I went with my gut that I have regretted. If anything, my deep love of Linguistics and anything Language, which I explored in College, can propel me forward and be applied to tech as well. Because what is a programming language but just another language.