DEV Community: Donte Ladatto

Async Redux: Updating 2 Slices at Once

Donte Ladatto — Thu, 27 Apr 2023 13:21:17 +0000

Allow me to paint a scenario: you have a React application that connects to a relational database (let's say you're using Ruby on Rails' Active Record). You are using asynchronous Redux with Thunk (Check out Redux Toolkit!) to fetch data from three different models and save them into state.
The models and their relationships are as follows:

So would we need to create a slice for all three models in order to manage all of our state? Well, no. Assuming that both a user and a movie are serialized to include an array of their reviews, a reviewsSlice isn't necessary; all of the reviews can be accessed and updated through association methods. That leaves us needing one slice to handle the current user in the session hash (sessionsSlice), and another to manage the movies from the database (moviesSlice).

// Asynchronous action creator sends a GET request to your
// SessionsController in the back end
export const fetchUser = createAsyncThunk("sessions/fetchUser", () => {
  return fetch("/your-route-for-the-current-user")
    .then((response) => response.json())
    .then(data => data) 
});

const sessionsSlice = createSlice({
  name: "sessions",
  initialState: {
    currentUser: {},
    status: "idle",
  },
  reducers: { ... },
  extraReducers: builder => {
// Dispatching fetchUser() in the front end will run the .pending
// action first, then the .fulfilled action when the response from
// the GET request comes back
    builder
      .addCase(fetchUser.pending, (state) => {
        state.status = "loading";
      })
      .addCase(fetchUser.fulfilled, (state, action) => {
        state.currentUser = action.payload;
        state.status = "idle";
      })
  }
// We can directly mutate state thanks to Immer, included in the
// Redux Toolkit!

The code to get the movies will look very similar; only the endpoint in the fetch and the initialState should differ (and the name of the slice and async action, but you knew that, right?).
Now when we access state, we should be able to call currentUser.reviews (or .reviews on any given movie) and render accordingly. We have all of our data in state, and it only took two fetches! But how do we update state in both slices whenever we create, edit, or delete a review? Are we sending two POST requests? Heck no!
The key is going to be writing additional actions to dispatch alongside your review-related requests. A review has both a user_id and a movie_id, so it would make sense to at least have your create and update actions in the back end be through one of these associations. Since the current user is the one performing these actions, it makes the most sense to create and update using their id. Thus, we will be performing all of our asynchronous actions in sessionsSlice:

export const addReview = createAsyncThunk("reviews/addReview",
 (reviewObj) => {
  return  fetch('/reviews', {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(reviewObj)
  })
  .then(r => r.json())
  .then(data => data) // this line gives us our action.payload,
                      // i.e. the new review
})
// Down in extraReducers...
 .addCase(addReview.pending, (state) => {
    state.status = "loading";
 })
 .addCase(addReview.fulfilled, (state, action) => {
    state.currentUser.reviews.push(action.payload);
    state.status = "idle";
 })

You can see from the above code that we are passing in a 'reviewObj' parameter for the body of the POST request. This is simply the controlled form data from your review creating component and the id of the movie being reviewed:

const reviewObj = {
      movie_id: movie.id, // from props
      content: form.content, // from controlled form 
      rating: form.rating,
  }

So if you can pass this object in when you dispatch addReview, you can also use it to update the movie's reviews, right? Well, let's see...

const moviesSlice = createSlice({
  name: "movies",
  initialState: {
    entities: [], // array of movies
    status: "idle", // loading state
  },
  reducers: {
    addMovieReview(state, action) {
      const movie = state.entities.find(m => m.id ===
        action.payload.movie_id);
      movie.reviews.push(action.payload)
  }
 }
// And in the review form component...
const handleSubmit = (e) => {
    e.preventDefault()
    dispatch(addReview(reviewObj))
    dispatch(addMovieReview({ 
      ...reviewObj,
      user_id: currentUser.id // brought in from the store
    }))
  }

Now both the user's reviews and the movie's reviews are updated with one click, and Redux automatically rerenders the app to reflect the changes. While this seems alright on the surface, there is one glaring issue: there is no accounting for failure. If the review doesn't pass validations on the back end, we get an error pushed into our user reviews and an invalid review attributed to our movie. So how do we fix this?
We start by removing the second dispatch from our review form's handleSubmit. There's nothing wrong with the addMovieReview action, we just won't be calling it here. Next we will be adding a few things in sessionsSlice: error handling and some shiny new variables in initialState.

name: "sessions",
  initialState: {
    currentUser: {},
    review: null, // for storing a new/updated review instance
    errors: [], // to push error messages into
    status: "idle"
  },
  reducers: {
// We'll throw some new actions in here so we can update our 
// new variables from the components
    setReview(state, action) {
      state.review = action.payload
    },
    setErrors(state, action) {
      state.errors = action.payload
    }
   },
  extraReducers: builder => {
    builder
      .addCase(addReview.pending, (state) => {
        state.status = "loading";
      })
      .addCase(addReview.fulfilled, (state, action) => {
// Here we conditionally handle the error key that we return
// from the back end, should it show up in our response
        if (action.payload.error) {
          state.errors = action.payload.error
          state.status = "idle"
        }
        else {
// If the payload does not contain the error key, we can add
// the new review to the user object in state and store it
// inside of our new review variable as well
          state.currentUser.reviews.push(action.payload);
          state.review = action.payload
          state.status = "idle";
        })
    }
 }

The two new variables can now be used in combination with the useEffect hook at our app's top level component. The errors variable can be used to inform the user should their request go awry. I like to use a pop-up or overlay to render the errors, with a 'dismiss' or 'x' button that can dispatch(setErrors(null)) on click, but you could also opt to reset the errors inside of addReview.fulfilled after a successful post is made. More importantly, we can now finally add our new review to its respective movie. Behold:

// App.js
const review = useSelector(state => state.sessions.review)

useEffect(() => {
    if (review) {
      dispatch(addMovieReview(review))
      dispatch(setReview(null))
      // Here you can programmatically navigate to another page,
      // or anything else you want to do after a review is created
    }
  }, [review])

So for a quick rundown:

The user submits a new review, dispatching the addReview action in sessionsSlice
If the review clears validations, it is added into state in sessions.currentUser.reviews and stored in sessions.review
The review variable is pulled from state in the application's top-level component, triggering a useEffect the second it becomes a truthy value (i.e., the new review instance)
The useEffect dispatches two actions: one to add the new review to the corresponding movie, and the other to reset the review variable to null

And there you have it! Two slices of state updated with a single click (though there's a lot more going on behind the scenes)! This same flow can be applied to update and destroy actions as well, with the use of the review-in-question's id. See if you can get it figured out on your own, or check out the Redux Toolkit documentation, where there's certain to be a way better solution that I overlooked. You've got this! Shoot, if you made it through this roller coaster of a blog, there's probably nothing you can't do.

ActiveModel::Serializer and You

Donte Ladatto — Fri, 23 Sep 2022 17:21:29 +0000

Today I thought I'd run through a few of the powerful things that the ActiveModel::Serializer gem brings to the table when used in a Ruby on Rails application. Sure, there are faster alternatives, but AMS is the first one I learned how to use, and thus it holds a special place in my heart. Quick question before we dive too much deeper, though...

Why even use serializers?

If you've ever constructed an API using Rails, chances are you at least have a surface level understanding of what serializers are. You may think them unnecessary; why bother creating a whole new file when you can just dictate the shape of your response right inside of your controller action? For example, you have an index action and all you need it to do is send back a JSON response with all of the objects and their attributes minus the timestamps:

class ObjectsController < ApplicationController

  def index
    objects = Object.all
    render json: objects, except: [:created_at, :updated_at]
  end

end

This works just fine, and I'll grant that it does seem a little extra to deploy a serializer for such a small task. But consider the model-view-controller (or MVC) architecture, in which the controller's purpose is to take the client request and communicate with the model to deliver a response to the view layer. With separation of concerns in mind, determining how to display the response data to the user would seem to fall more under the view umbrella, no? So let's add AMS to our gemfile and play around with some serializers!

Creating a serializer with AMS

When you add ActiveModel::Serializer to your Rails application, the rails generate resource command will automatically create a serializer for the new model. You can also generate a serializer for an existing model, but it's important to follow the correct naming conventions. Unlike controller names, serializers are named after the singular form of the model. If we want to generate a serializer for our Object model, we can type:

~$ rails g serializer object

... and then ObjectsController will inherently know where to send the data to be serialized.

Serializing Associations

Now I'd wager that you're familiar with the belongs_to, has_many, and has_one macros that you can use in model files to establish modular relationships (if not you can go here and I'll have your money the next time I get paid). Those can also be applied in serializers! Let's imagine some sort of card-collector app, where we have a User object that can have many Card objects...

class UserSerializer < ActiveModel::Serializer
  attributes :id, :username
  has_many :cards
end

class CardSerializer < ActiveModel::Serializer
  attributes :id, :name, :year, :grade
  belongs_to :user
end

Now a Card will be serialized with a nested User object, and a User object will be serialized with an array of that user's cards among its attributes. The nested data will of course have gone through its own serializer, but what if we don't want all of the provided attributes? We can use namespacing to achieve a more streamlined response...

class UserSerializer < ActiveModel::Serializer
  attributes :id, :username
  has_many :cards
  class CardSerializer < ActiveModel::Serializer
    attributes :name
  end
end

... and our User object will contain an array of Card objects with only the name attribute. Alternatively, a custom serializer can be created to accomplish the same result:

~$ rails g serializer user_card

class UserCardSerializer < ActiveModel::Serializer
  attributes :name
end

class UserSerializer < ActiveModel::Serializer
  attributes :id, :username
  has_many :cards, serializer: UserCardSerializer
end

Both methods will result in a User object that looks like this:

{
  "id": 1,
  "username": "mikeyb",
  "cards": [
    {
      "name": "Mickey Mantle"
    },
    {
      "name": "Charizard"
    },
    {
      "name": "Tom Brady"
    }
  ]
}

Now for the best part...

Custom Methods

That's right, we can pretty much do whatever we want to our data in here. Let's go back to our ObjectSerializer. On second thought, let's call it ItemSerializer to save us from some confusion down the line. We'll say that an Item has a weight attribute that's stored in the database as an integer. So right now, our JSON response will contain something like "weight": 65. Seems kind of vague, right? Could be ounces, could be tons. We know that the numbers in the database represent kilograms, but how do we make that known in the view layer? How about we overwrite the weight attribute with a custom method?

class ItemSerializer < ActiveModel::Serializer
  attributes :id, :name, :weight

  def weight
    "#{object.weight}kg"
  end
end

And voila, our theoretical response body will now contain "weight": "65kg". You might be asking why we called object.weight instead of self.weight. This is because self in this case refers to an instance of ItemSerializer. However, this instance does contain an "object" attribute, and inside of that is the Item instance. So to access the Item's weight, or any other attribute, we must type self.object.weight (or just object.weight).
Our newfound powers don't stop at just overwriting existing attributes, though. Not everyone subscribes to the metric system, so let's put an imperializer in our serializer!

class ItemSerializer < ActiveModel::Serializer
  attributes :id, :name, :weight, :weight_in_lbs

  def weight
    "#{object.weight}kg"
  end

  def weight_in_lbs
    pounds = object.weight * 2.20462262185
    "#{pounds.round(1)} lbs"
  end
end

Yes, we can essentially create our own attributes on the fly. An Item object sent to the client will now look something like:

{
  "id": 1,
  "name": "Coffee Table",
  "weight": "65kg",
  "weight_in_lbs": "143.3 lbs"
}

So are you using ActiveModel::Serializer yet? Don't you want to feel the power? Here's another link so you don't have to scroll all the way up. It's time to get serious about serializing.

Relationship Advice... for Tables

Donte Ladatto — Fri, 01 Jul 2022 20:30:32 +0000

You can't spell relatable without table!
... Okay, sorry about that. What I'm not sorry about is practicing creating relational databases. Forging relationships between data in different tables can either be a simple, straightforward process, or it can make your head spin. It can help to concoct an example or two (or three) to really help you visualize and then implement these connections in order to create your very own API, especially if you are new to the concepts. In this blog, I'm going to run through one such example using Ruby and the Active Record gem.
Let's say you're making an application that allows users to catalog and keep track of their book collection. Well, you'll definitely need a books table. It might look something like this:

At first glance, this is a perfectly fine way to store all the information for a book. But what if you wanted to add more information about the author? Hometown, date of birth, favorite color, or what have you. Sure, you could add those columns to your books table, but is it really The Shining's business to know that Stephen King's favorite food is cheesecake? Hardly, and imagine having to put all of that info in every single time you want to create a Book instance! Fortunately, there's a better way to go about this. We're going to split the author column off into its own table and connect it to our books table by using what's called a foreign key. First, consider the relationship between books and authors - a book belongs to an author, and an author can have many books (a book can have many authors as well, but let's not talk about that right now). This defines a pretty cut and dried example of a one-to-many relationship, wherein the one is the author and the many represents the books by said author. With this knowledge in tow, we can now replace the "author" column in the books table with our foreign key, "author_id". This will be an integer that points to the id column (or primary key) of the Author instance that the Book belongs to:

Now that we've made this connection, it's time to add macros to our Ruby models to reflect the change:

class Book < ActiveRecord::Base
   belongs_to :author
end

class Author < ActiveRecord::Base
   has_many :books
end

With the "author_id" column in our books table and the new macros we've put in our classes, Active Record will create an association between these models and generate all new methods for us! You can now call .books on an Author and get back an array of all of the Book instances that belong to them. Likewise, calling .author on a Book will return the Author instance that it belongs to. Neat!

Taking another look at our books table above, we can see another potential issue; what if a book has many genres that can be attributed to it? Surely we don't want to cram them all into that one space, as that could make searching for books of a certain genre a little bit messy later on. We'll start by creating a Genre model and corresponding genres table, then get to work on forming an association between books and genres. A book can have many genres, but a genre can also be attributed to many books. We can't simply plop a foreign key into one of the tables and call it a day in this scenario. Instead, we're going to establish what's called a many-to-many relationship. This involves creating a join table with a foreign key from both parties involved:

Our join table, book_genres, froms a connection by taking the id of a Book and a Genre and turning that relationship into an instance of its own (so we will need to add a BookGenres model). Now for our macros...

class BookGenres < ActiveRecord::Base
   belongs_to :book
   belongs_to :genre
end

class Book < ActiveRecord::Base
   belongs_to :author
   has many :book_genres
   has many :genres through: :book_genres
end

class Genre < ActiveRecord::Base
   has many :book_genres
   has many :books through: :book_genres
end

... and voila! An instance of Book now has the self.genres method, and an instance of Genre has the self.books method. It may seem like extra work to construct a "middleman" class like BookGenres, but think just think about the work that you aren't having to do thanks to Active Record (it really is a gem)! Now imagine if users were given the option to leave reviews. Can you envision another many-to-many relationship taking place? One in which a book has many reviews, many readers through reviews, and vice-versa?

In conclusion, relationships between tables of data mirror those of the real-life objects that the data represents. Once you start thinking along those lines, and hash out a couple of examples like this one, creating associations between your tables is a breeze... especially with Active Record doing all the dirty work under the hood.

Tables created with the help of Miro.

The Dark Side of useContext

Donte Ladatto — Fri, 20 May 2022 20:42:49 +0000

I don't know about you, but I'm a sucker for dark mode. So much so that the first thing I do whenever I open up a new app is look for a way to turn the lights out. In addition to being more aesthetically pleasing (everything on the page really pops against a dark backdrop), dark mode also makes navigation easier, with all the text and buttons shining forth like stars in the night sky. Aaand it's easier on the eyes if you yourself are in a literal dark place. With so many pros and absolutely zero cons, working this particular feature into your React application should be a no-brainer! Let's review a couple of (sort of) different ways to bring your app into the dark ages before moving on to what I consider the optimal solution.

useState: True or False

In React, adding a dark mode toggle is as simple as creating a state variable that will be used to control the CSS styling being applied to the page. If you aren't familiar with the useState hook for React, check out the docs here. In this first method we will be using a Boolean value as a state variable:

// ./src/components/App

import React, { useState } from 'react'
import ChildComponent from './ChildComponent'

const App = () => {
  // Create state variable for dark mode with a default value
  // of false
  const [darkMode, setDarkMode] = useState(false)

  // Write callback function for the toggle button;
  // can also be written inline as 
  // () => setDarkMode(darkMode => !darkMode)
  function changeMode() {
    setDarkMode(darkMode => !darkMode)
  }

  return (
  // Use ternaries to dynamically update the div className
  // and button text
    <div className={darkMode ? "App Dark" : "App"}>
      <header>
        <h2>My App</h2>
        <button onClick={changeMode}>
          {darkMode ? "Light Mode" : "Dark Mode"}
        </button>
      </header>
  // Pass down state variable through props for children to use
      <ChildComponent darkMode={darkMode} />
    </div>
  );
}

export default App;

This method is best for when you only want to use a single button or checkbox to switch between two modes. If you wanted to give the user more than two themes to choose from, however, a Boolean value simply won't cut it.

useState with a String Variable

// ./src/components/App

import React, { useState } from 'react'
import ChildComponent from './ChildComponent'

const App = () => {
  // Create state with a default value of "App",
  // the default option of your dropdown below
  const [theme, setTheme] = useState("App")

  // Write callback function for dropdown to update state
  function handleThemeChange(e) {
    setTheme(e.target.value)
  }
  return (
    <div className={theme}>
      <header>
        <h2>My App</h2>
        <select name="theme" onChange={handleThemeChange}>
  // Option values equal CSS classes (.App.Dark, etc)
          <option value="App">Select Theme</option>
          <option value="App Dark">Dark Mode</option>
          <option value="App Blue">Ocean</option>
          <option value="App Purple">Galaxy</option>
        </select>
      </header>
  // Pass down state value through props
      <ChildComponent theme={theme} />
    </div>
  );
}

export default App;

Setting your state variable as a string will work whether you have two modes or twenty, giving you the flexibility to add more themes later on if you so choose.

These methods work just fine if your styling is simple enough to be handled at the App level alone, or even in an extra child component or two. What if you're working with a more extensive component hierarchy, with many elements that require different CSS styling? Sure, you could pass down your state variable through generations of components using props, but that can become tedious and messy. Let's get acquainted with another React hook!

Add a Dark Mode to Your App with the useContext Hook

The use of context in React is best reserved for situations where many components need access to the same data. Data like, I don't know, a state variable that controls what the entire app looks like? We'll start by creating a new JS file for the context we want to create, and then moving our state variable into it:

// ./src/context/theme

import React, { useState } from "react";
// Create a new Context object with... React.createContext()
const ThemeContext = React.createContext();

// Create your Provider component, and set its value to an
// object containing everything to be passed down to consumers
function ThemeProvider({ children }) {
// The state you created before now lives here
  const [theme, setTheme] = useState("App");

  return (
    <ThemeContext.Provider value={{ theme, setTheme }}> 
    {children}
    </ThemeContext.Provider>
)}

export { ThemeContext, ThemeProvider }

Then we'll want to wrap all components that need to use our new context with our provider. In this case we'll be going straight to our index.js file to wrap the App component with 'ThemeProvider':

// ./src/index

import React from "react";
import ReactDOM from "react-dom";
import App from "./components/App";
import "./index.css";
import { ThemeProvider } from './context/theme'

ReactDOM.render(
<ThemeProvider>
<App />
</ThemeProvider>,
document.getElementById("root"));

Finally, each component that will be utilizing our theme context will have to import two new things: useContext from React, and ThemeContext. You then deconstruct the values you want to take from ThemeContext with the useContext hook and can use them freely:

// ./src/components/App

import React, { useContext } from "react";
import ChildComponent from "./ChildComponent";
import { ThemeContext } from "../context/theme";

function App() {
// Pass your new Context object (ThemeContext) as an
// argument to useContext, which returns the current value
// of the Context object, and destructure the data you need
  const { theme, setTheme } = useContext(ThemeContext)

  function handleThemeChange(e) {
    setTheme(e.target.value)
  }
  return (
    <div className={theme}>
      <header>
        <h2>My App</h2>
        <select name="theme" onChange={handleThemeChange}>
          <option value="App">Select Theme</option>
          <option value="App.Dark">Dark Mode</option>
          <option value="App.Blue">Ocean</option>
          <option value="App.Purple">Galaxy</option>
        </select>
      </header>
  // No passing props here! If ChildComponent needs to know
  // about theme, it can talk to our new friend Context
      <ChildComponent />
    </div>
  );
}

export default App;

Gone are the days of passing down props, sometimes through components that don't even use them, to experience the glorious brilliance of dark mode (or any other user-selected themes) throughout your applications. Context grants us the ability to pump in our state and/or setter function wherever is necessary, giving us dark mode with cleaner code. Welcome to the dark ages... in a good way!

The Making of Ghibli Watch

Donte Ladatto — Thu, 07 Apr 2022 01:19:26 +0000

About the App

Ghibli Watch is my first attempt at creating a single page application centered around Javascript events, DOM manipulation, and server communication. My significant other is a big Studio Ghibli fan, and I've really enjoyed the few films I've seen as well. The beautiful hand-drawn animation and oft fantastical storytelling pair well to provide an enchanting viewing experience, and I'm here for more! Thus, I set out to create an application that would allow myself and others like me to discover and compile lists of Studio Ghibli films (with the help of this wonderful API). Below I will detail the problems I encountered, along with the steps I took to solve them. I do this not only to further my own understanding, but to also help others who might find themselves in similar situations down the road. Now, without further ado...

How do I take the data I GET from the API and POST it to a local database?

This is the first big question I had during the building process. I knew how to fetch the data and append it to the page, but for users to be able to add the selected film to a list and have it persist, I needed to be able to send that same data to another database (in this case, a mock back-end created using JSON Server). Being relatively new to this sort of thing, this initially seemed like a daunting prospect. After couple of moments of consideration, the simple solution materialized; save the keys from the dataset as variables to use in the body of my 'POST' configuration object and add the event listener for the buttons all within the same function.

function displayFilm(e) {
    fetch(BASE_URL + `/${e.target.id}`)
    .then(res => res.json())
    .then(data => {
        let image = data.movie_banner
        let title = data.title
        let year = data.release_date
        let desc = data.description
        display.innerHTML = 
        `<img class="resize" src="${image}">
        <h1>${title} <span class="year">${year}</span></h1>
        <p>${desc}</p>
        <button class="watch">Add to Watchlist</button>
        <button class="favorite">Add to Favorites</button>`

        display.addEventListener('click', (e) => {
            let endpoint;
                if (e.target.className === "watch") {
                    endpoint = "/watchlist"
                }
                else if (e.target.className === "favorite") {
                    endpoint = "/favorites"
                }
                    fetch(LOCAL_URL + endpoint, {
                        method: 'POST',
                        headers: {
                            "Content-Type": "application/json",
                            Accept: "application/json"
                          },

                          body: JSON.stringify({
                            "movie_banner": image,
                            "title": title,
                            "release_date": year,
                            "description": desc
                          })
                    })
                }
            })
        )
    })
}

This worked like a charm, or so it appeared...

Why am I sending multiple POST requests with one click?

This one's admittedly a little silly looking back, but it was a real headache for me for a while. I had added my event listener like so:

//Defined globally
const display = document.querySelector("#show-panel")
//Inside film rendering function
display.addEventListener('click', (e) => {...}

The problem with this was that the listener was attached to an existing HTML element, instead of one created by my film rendering function. So while display.innerHTML = "" would reset the display window every time a film was rendered, the event listeners would stick around. This resulted in unwanted post requests being made from presumably clicking one button.
I corrected this by adding an event listener to each button as they were created, but I could also have added a nested div to the rendered HTML and attached my singular listener to it instead.

                const addWatch = display.querySelector(`.watch`)
                const addFav = display.querySelector(`.favorite`)
                const postConfig = {
                    method: 'POST',
                    headers: {
                        "Content-Type": "application/json",
                        Accept: "application/json",

                    },

                    body: JSON.stringify({
                        "movie_banner": image,
                        "title": title,
                        "release_date": year,
                        "description": desc
                    })
                }
                addWatch.addEventListener('click', (e) => {
                    fetch(LOCAL_URL + '/watchlist', postConfig)
                        .then(res => res.json())
                })
                addFav.addEventListener('click', (e) => {
                    fetch(LOCAL_URL + '/favorites', postConfig)
                        .then(res => res.json())
                })

How do I keep duplicate data from being posted?

One of my main concerns going into this project was how I was going to keep films from being added to the same list twice. My first thought was to disable the buttons on click...

                addWatch.addEventListener('click', (e) => {
                    fetch(LOCAL_URL + '/watchlist', postConfig)
                        .then(res => res.json())
                    e.target.disabled = true
                })

... but the film could still be added again the next time it was rendered. No, the answer was to assign an ID to each film inside of the configuration object. So:

//I assign the ID key from the API to a variable...
let eyeD = data.id

//... then add this new variable to my POST configuration object
"id": eyeD

Voila! Now a duplicate POST request throws a 500 (Internal Server Error) in the console. Now to alert the user...

//Each one following its respective fetch:
.catch(error => alert(`${title} is already on your watchlist!`))

.catch(error => alert(`${title} is already in your favorites!`))

And now, a quandary born of aesthetics...

Behold, the list view when there is data to be rendered:

But when the fetch comes up empty:

Blech. I wasn't a fan of how that looked. Let's take a peek at the list rendering function:

function displayList(e) {
    display.innerHTML = ""
    let endpoint;
    let header;

    if (e.target.id === "watchlist") {
        endpoint = "/watchlist"
        header = "My Watchlist"
    }
    else if (e.target.id === "favslist") {
        endpoint = "/favorites"
        header = "My Favorites"
    }
    display.innerHTML = `<h2>${header}</h2>`
    fetch(LOCAL_URL + endpoint)
        .then(res => res.json())
        .then(data => data.forEach(film => {
            display.innerHTML += `<div class="card"><img id="${film.id}" class="thumbnail" src="${film.movie_banner}"><br>
        <h3>${film.title}</h3><button class="delete" id="${endpoint + "/" + film.id}">Remove from List</button><br><br></div>`
        }))
}

As we can see, the function makes a GET request to the local server with an endpoint determined by the ID of the button that was clicked, and then appends data from the returned promise object to the DOM. But what if there isn't any data? Apologies to Taylor Swift, but I don't want to see any blank space.

How can I display a message when a GET request returns an empty promise object?

Right off the bat, I knew that any change I was going to make would have to be within my fetch. Number two, I knew that I wanted to add new HTML if there was no data to display. Ah-ha, an if statement! But how do I write out my condition? Taking a look at my db.json file, I see this: "watchlist": [],. It's an empty array.

fetch(LOCAL_URL + endpoint)
        .then(res => res.json())
        .then(data => {
            if (data.length === 0) {
                display.innerHTML += `<p class="empty">You haven't added anything to this list yet; select a film and get started!</p>`
            }
            else {
                data.forEach(film => {
                    display.innerHTML += `<div class="card"><img id="${film.id}" class="thumbnail" src="${film.movie_banner}"><br>
        <h3>${film.title}</h3><button class="delete" id="${endpoint + "/" + film.id}">Remove from List</button><br><br></div>`
                })
            }
        })

Boom, if (data.length === 0). But if I were to remove every film from the list, we're back at square one with the blank space (until another user input resets the display). So I also needed to add to my delete functionality:

document.addEventListener("click", (e) => {
    if (e.target.className === "delete") {
        fetch(LOCAL_URL + `${e.target.id}`, {
            method: "DELETE"
        })
            .then(res => res.json())
            .then(res => {
                e.target.parentElement.remove()
            })
    }
})

I knew I would be writing another if statement, but I couldn't use the same method I did with the GET request because DELETE doesn't return anything but a status code (I just type .then(res => res.json()) to reinforce the habit). But in this scenario, the ugly blank space is a direct result of me removing elements from the DOM. So I simply need to tack on a .then() with an if statement that checks if a certain element is present or not...

.then(res => {
                if (document.querySelector(".card") === null) {
                    display.innerHTML += `<p class="empty">You haven't added anything to this list yet; select a film and get started!</p>`
                }
            })

When will I see that blank space again? "Quoth the Raven..." etc.

It was a small change, but a necessary one.

In Conclusion

This project, though small in size, afforded me plenty of learning opportunities through research, trial and error. I hope to use this experience in continuing to build grander works in the near future. I also hope that if nothing else you were able to laugh at my follies. 'Til next time!

The Ladatto Code

Donte Ladatto — Mon, 04 Apr 2022 16:18:33 +0000

I've always taken great pride in building things. From Lincoln Logs and Tinkertoys to K'nex and Legos, to then countless hours of Minecraft, my life thus far has been full of creative construction. There is no greater feeling to me than to look upon a finished project and think with satisfaction, I made that.

Throughout high school and heading into my first two years of college, I thought I wanted to become an architect. After an introspective year off, I realized that while designing structures definitely interested me, it was really only half of the thrill. I wanted to build as well, to see my designs come to fruition through the use of my own two hands. I needed to find a new calling, but in the meantime I took a job dealing table games at a casino. The meantime turned out to be a long time, and seven years had passed before I decided to delve into coding alongside some close friends of mine.

With code, I believe I have finally found what I've been looking for. I have the means to create anything within the scope of my imagination, using components spun from my fingertips. Learning new syntaxes is simultaneously daunting and exhilarating, but after each foray into new material I emerge with another tool to add to my repertoire. It's an incredibly rewarding and fulfilling experience, and I'm only just scratching the surface.

Now, let's have some fun with my above ramblings:

const ramble = `I've always taken great pride in building things. From Lincoln Logs and Tinkertoys to K'nex and Legos, to then countless hours of Minecraft, my life thus far has been full of creative construction. There is no greater feeling to me than to look upon a finished project and think with satisfaction, I made that. Throughout high school and heading into my first two years of college, I thought I wanted to become an architect. After an introspective year off, I realized that while designing structures definitely interested me, it was really only half of the thrill. I wanted to build as well, to see my designs come to fruition through the use of my own two hands. I needed to find a new calling, but in the meantime I took a job dealing table games at a casino. The meantime turned out to be a long time, and seven years had passed before I decided to delve into coding alongside some close friends of mine. With code, I believe I have finally found what I've been looking for. I have the means to create anything within the scope of my imagination, using components spun from my fingertips. Learning new syntaxes is simultaneously daunting and exhilarating, but after each foray into new material I emerge with another tool to add to my repertoire. It's an incredibly rewarding and fulfilling experience, and I'm only just scratching the surface.`

How many times did I say 'I'?

const rambleArr = ramble.split(" ")

rambleArr.filter(word => word === "I").length
//12

Huh. That's fewer than I thought. And?

rambleArr.filter(word => word === "and").length
//8

Longest word?

rambleArr.reduce((a, b) => a.length < b.length ? b : a, "")
//'simultaneously'

Fun! But wait; I've now noticed that rambleArr contains words with punctuation attached to them. This really could have interfered with the methods I've been using. One quick Google search later and I've been introduced to the wonderful world of regex operators!

const wordBoundaryArr = ramble.split(/\b/)

I've blown up my contractions, now how many times did I actually refer to myself...

wordBoundaryArr.filter(word => word === "I").length
//15

Very cool, and an excellent example of why I love coding. I learned something new just by goofing around! Yes, I have indeed found what I've been searching for.