DEV Community: loren-michael

E-Commerce using Redux

loren-michael — Wed, 24 May 2023 18:01:00 +0000

The time to show off my skills is here! For my final project for Flatiron I built an application that mimics sites like Etsy, eBay and (specifically) Reverb. It is a website called "Sell It!" that allows users to sign up and list their audio gear or instruments to sell to other users. As one of our learning goals for this project, we needed to implement Redux in our application.

Redux was a blast to utilize. It made state data so much easier to manage. At first the setup was a little confusing and sometimes updating data can get a little twisted, especially if you're using any nested data in your site, but it's worth figuring it out and learning a new thing that streamlines prop sharing.

Redux gives the developer of an app a single, centralized place where our state data is contained. This eliminates the need for prop sharing through a tree. It also requires a specific pattern to be followed in order to update state.

There are a handful of new terms that you need to learn when utilizing Redux. Here's a quick rundown of the different functions:

Store: The store is where the current Redux application state lives. When we set up our application, we create the store in our index.js file so that immediately upon loading, the user has access to current data. This is also where we can implement other Redux middleware that I will not be covering in this blog post.

const store = createStore(rootReducer, composeWithDevTools(applyMiddleware(thunk)))

Action: An action is a JavaScript object that has a "type" field. An action is an event that describes what event is happening in the application. For example, addItem would be a good action name to describe adding an item to your store.

export const addItem = item => {
  return (dispatch)  => {
    dispatch({ type: "CREATE_ITEM", payload: item })
  }
}

Dispatch: The Redux store has a method called dispatch. The only way to update state is to call dispatch() and pass in an action object. Here you can see a short function that is triggered by an event (pushing a delete button) that dispatches the deleteItem action with an id being passed to the action.

  function handleDeleteListing (e) {
    dispatch(deleteItem(e.target.id))
  }

Reducers: A reducer is a function that

Receives the current state and an action object
Decides how to update state if necessary
Returns the new state A reducer functions similarly to an event listener based on the action it receives.

Above I showed the addItem action, that dispatches an object. In the object is a "type" key whole value is "CREATE_ITEM". When dispatched, the reducer looks for the matching action type and updates and returns state based on the data being sent in the payload value (in this case, the new item).

const itemsReducer = (state=initialState, action) => {
  switch(action.type) {
    case "CREATE_ITEM":
      return {
        ...state,
        items: [...state.items, action.payload]
      };
    default:
      return state;
  }
}

Selector: The selector function is used in any component where you need to access the store. When it's time to access the store to display the items, we define our variable and then "select" the data from the store that we want to access. Below I've shown two different ways of defining what data we want to access from which reducer (store.items or store.sessions).

  const items = useSelector(store => store.items)
  const { loggedIn, currentUser } = useSelector(store => store.sessions);

The way that data flows one way through Redux is brilliant.

First, state describes the condition of the app at that point in time, and UI is rendered based on that state.

Next, when an event occurs in the app, an action is dispatched.

The store looks through the reducers to find the correct action type and updates state based on the action and the action's payload.

Then, the store tells the UI that there has been an update to the state, triggering a re-render based on the new state.

It's been a really great tool to use and I can't wait to build another app that uses Redux!

Ruby on Rails: A Simple Movie Rental Application

loren-michael — Mon, 13 Feb 2023 20:12:25 +0000

Over the last couple months I've been diving deeper into Rails. Learning how to connect a React frontend to a Ruby on Rails backend was honestly pretty smooth. In building out this application I discovered a couple of weak points in my learning and will be able to course correct easier in the future because of this experience.

A lot of the lessons that I got out of this project revolved around establishing a good order of operations. When you're building a house, you start with foundations, then framework, then plumbing and electric, then finally walls and a roof. I think a lot of my early struggles in building my own apps has stemmed from losing sight of this particular lesson. While it can be difficult to stop and pivot to a different task, it really helps to exercise the brain while learning new things to rotate subjects in and out - set up a database model, seed it, switch to React and build it out, repeat. Going back and forth from setting up a database model to making sure that the frontend will receive the data it needs is incredibly helpful. Setting up your frontend components earlier in the process will also give you a better idea of what kind of data you will need to provide from your database. In my case, it would have helped me decide exactly what keys I would want for my movies model, rather than guessing and adding more information than I really needed.

For this application, I built out a database that included Movies, Rentals, Stores and Users, with Rentals set up as a join table for the other 3 models. When a User starts a rental, the User's id, Movie id and Store id are stored together with a Rental id. When fetching rentals from the backend, we also include the associated movie for easy iteration.

Near the end of my project phase, I was tasked to learn a hook, useContext. I found this hook to be incredibly useful with this application. When you implement useContext, you allow your data to move freely around your component tree, rather than having to send it through a hierarchy to reach the components that access it (often passing through components that don't). This hook potentially saves a lot of time in larger applications with many nested components.

To utilize the useContext hook in this app, I followed these steps:

Create a context folder within my src folders (where both components and context share the src as a parent directory). Inside that folder, I made a file for each of the models that I wanted to use with the useContext hook. In this case, I made a movies.js file and a stores.js file.
Once these files are set up, we add the following code to them:

import React, { createContext, useState } from "react";

const MoviesContext = createContext(null);

const MoviesProvider = ({ children }) => {
  const [movies, setMovies] = useState([])

const value = [movies, setMovies]

  return (
    <MoviesContext.Provider value={value}>
      { children }
    </MoviesContext.Provider>)
}

export { MoviesProvider, MoviesContext }

First we import React and createContext as well as any other relevant hooks to the context we are creating. The next line just sets up MoviesContext as our newly created context. This can start either empty or with a null value.

Then we need to create our Provider. The provider acts like a component, in which we can set up things like state and determine what gets returned to the Context Provider when it is called in other components. Our provider has a prop of children because we want this provider and the information it holds to be available to any of the children of its element in our index.js file. We'll get to that in a moment.

Within the return block of the Provider, we need to tell the <MoviesContext.Provider> element what information we want it to provide using the value tag. Here, I am setting movies and setMovies within my value tag. Within the element we include the { children } prop to specify that the value is available to all children of the element.

Last, we need to export our Provider and Context.

Next the Provider needs to be added to the main index.js file. Remember, all children of this Provider will be able to access the information, so we want to nest our <App /> element within the Provider. It looks like this:

import React from 'react';
import ReactDOM from 'react-dom/client';
import './index.css';
import App from './App';
import { MoviesProvider } from './context/movies';

const root = ReactDOM.createRoot(document.getElementById('root'));
root.render(
  <React.StrictMode>
    <MoviesProvider>
      <App />        
    </MoviesProvider>
  </React.StrictMode>
);

Notice that we need to import our Provider from our context folder in order to use it in our render.

Then, we move into our components to access the Context that our Provider is making available to our App. In order to access the information, we first need to import our Context...

import { MoviesContext } from '../context/movies'

...define the props that we will be using...

const [movies, setMovies] = useContext(MoviesContext);
...and then continue to use these variables within our components the same as if they were passed down through our component hierarchy. Here's a full example of a component that uses the movies prop:

import '../styles.css';
import React, { useContext } from 'react';
import { Card } from 'semantic-ui-react';
import { MoviesContext } from '../context/movies'
import MovieCard from './MovieCard';

function MoviesContainer() {
  const [movies, setMovies] = useContext(MoviesContext);

  return (
    <div>
      <br></br>
      <Card.Group className="movie-cards">
        {movies.map(movie => {
          return (<MovieCard key={movie.id} movie={movie} />)
        })}
      </Card.Group>
    </div>
  )
}

export default MoviesContainer

It's always a challenge to learn a new hook. Luckily useContext is one of the easier ones to implement within an existing application. Just remember to remove any other code that defines, calls or passes down the original state props and you should be good to go!

Creating an App with React and Sinatra

loren-michael — Tue, 11 Oct 2022 18:48:44 +0000

To wrap up my current phase of learning, I've been tasked to create a React application that utilizes Sinatra. As an avid D&D fan, I decided that for this project I'd create a character manager. I thought it would be a challenging way to create a backend database of users who manage their characters. I also created a DB Diagram to show my tables and relationships:

As an added challenge to myself, I wanted to learn how to utilize a simple login prompt to better organize the characters and show proper ownership over each of them. I decided not to use any kind of password or authenticator, this is simply a persistent username based login. By using the browser's localStorage, I was able to set up a way for users to persist on different visits. When logging in, the app will look for an existing user in the database. If a user is found, a few different states get updated. A currentUser is set, isLoggedIn is set to true, we add a user id to localStorage, and then we navigate to a home page where all of that user's characters are displayed. The login code looks like this:

  const login = (user) => {
    setCurrentUser(user);
    setIsLoggedIn(true);
    localStorage.setItem('user_id', user.id);
    navigate(`/${user.id}/characters`)
  }

I then wrote a useEffect that would fetch the characters of a user whenever the currentUser state gets updated. When the user logs out, all of these states get reverted back to their default settings, including wiping out the state that stores the characters so that there are no data remnants from previous users. In order for this to work properly, I had to find a way to look up users in the backend when entering a username into the Login component. To do this, I wrote a fetch that would send the submitted username to the backend. The backend then searches for the username, and if it exists, sends back the user data and calls the login function shown above. If the user does not exist, it sends a message instead of user data, and the browser will alert the user that the username they are trying to log in with does not exist. (Currently I have not implemented a way to create a new user but I plan to add that in the future.)

On the frontend, the fetch takes the username and POSTs it to the server:

  const handleLogin = e => {
    e.preventDefault();

    fetch('http://localhost:9292/login', {
      method: "POST",
      headers: {
        "Accept": "application/json",
        "Content-Type": "application/json"        
      },
      body: JSON.stringify({ username })
    })
      .then(resp => resp.json())
      .then(data => {
        if(!data.message) {
          login(data)
        } else if (data.message) {
          alert(data.message)
        }
      })
  }

In this process I also learned that a project can have multiple Controller files to better organize your routes. When making additional Controller files, they need to be added to your config file so your application knows to access them for routes.
When we make this fetch, we use the SessionsController file, which has a route specifically for login requests. the route looks like this:

  post '/login' do
    user = User.find_by_username(params[:username])
    if user
      user.to_json
    else
      { message: "This user does not exist."}.to_json
    end
  end

The next step was writing a basic React frontend that would properly display all of a user's characters and allow the user to level up each of the characters (only to 20, naturally) and delete them if desired. But before being able to display data, I needed to create it! Using Active Record I created a migration for each of the tables that I wanted to utilize (Characters, Users and Games). In each of the migrations, I wrote out a create_table that included the information that I wanted to be able to store in each of the tables.

Here is the character table migration:

class CreateCharacters < ActiveRecord::Migration[6.1]
  def change
    create_table :characters do |t|
      t.string :name
      t.string :race
      t.integer :level
      t.belongs_to :game
      t.belongs_to :user
    end
  end
end

But wait! I forgot some columns! As I progressed with project development I went back to write additional migrations to add columns for character_class (since class is a reserved word, the column could not simply be named "class") and an icon, which holds the string of the URL for the icon images. While going through this process I also made a seed file that would create users, games and characters to test the application's functionality. Once seeded, I was able to display a user's characters after login:

As you can see, there are buttons on each character card that will allow the user to Level Up their character (to a maximum of 20 per traditional D&D rules) and delete them. The routes for these two tasks were fairly simple, either sending a new integer to PATCH to the character or destroying the entry.

This was a challenging way to reinforce everything that I've learned about React, Active Record, Sinatra, and even some basic Javascript/CSS. I look forward to learning so much more in the coming months!

Recipe Manager 2.0: React!

loren-michael — Wed, 22 Jun 2022 20:24:38 +0000

Over the past few weeks I've been learning React, and now it's time to show what I've learned. I decided to make a recipe manager similar to the one that I previously built using vanilla JavaScript. While it was relatively easy to make this transition, I definitely encountered some hiccups that required a little more troubleshooting than I anticipated.

After setting up my project and building my components, I made sure they would render by lining them up in my App and checking them in my browser. I then wrote a useEffect to fetch the recipes from my JSON database and stored that information in state so that any recipe can be rendered using a single fetch. Next, I started to distribute props and added Routes to the components. Right away I knew there was something wrong. The issue I encountered stemmed from using incompatible versions of React and React Router. Of course I figured out where the problem was after I wrote all of my Routes! Because I had installed v18 of React, I had to update my React Router from v5 to v6 and update all of the syntax around my Routes. Ultimately, updating the syntax didn't take very long and in the long run the new version looks much cleaner, so I'm actually glad I ran into this issue and learned a new and updated way of Routing.

From there, I was able to build out a home page using Semantic UI Cards. Each card shows a picture, the recipe title and whether or not the recipe is one of my favorites. Clicking on a recipe title will take you to the recipe's details page, where ingredients, instructions and any comments are displayed. Here is where you can add a comment or favorite/unfavorite a recipe.

This is where I ran into a common issue when using state in React. When updating state within a function, I would often try to utilize the updated state before the function finished and the changes were actually applied within the component.

For example, instead of changing whether or not a recipe was a favorite just by setting the "favorite" state:

function handleFavorite() {
    const newFavorite = !favorite;
    setFavorite(newFavorite);
};

I used a callback function within my setState hook:

function handleFavorite() {
    setFavorite(function (favorite) {
        const newFavorite = !favorite;
        return newFavorite;
    })
};

I then paired this function with a useEffect hook that is called whenever the "favorite" state is changed. Within the useEffect, the new "favorite" status gets PATCHed to the recipe database to make sure it is always current. At this point, the "recipes" state that is stored is no longer current, so I have the useEffect also fetch the updated database to store in the "recipes" state.

useEffect(() => {
     fetch(`http://localhost:3000/recipes/${recipe.id}`, {
        method: "PATCH",
        headers: {
           "Content-Type": "application/json"
        },
        body: JSON.stringify({"favorite": favorite})
     })
     .then(fetch(`http://localhost:3000/recipes`)
        .then(r => r.json())
        .then(recipes => {
           setRecipes(recipes);
}))
}, [favorite])

I used a similar process for the comments section, so that when a comment is submitted to the recipe, it updates the state of the "comments" array, which triggers a fetch within a useEffect that patches the new array to the database and then fetches the recipes to save into the "recipes" state to keep current with the database.

To set up all of these inputs as controlled inputs, I looked at my database and created a newRecipe state that had all of the keys that I wanted to include in the form. This includes things like the name of the recipe, the author, website, a photo URL, etc... When I got to the keys whose values were arrays, I simply included an empty array or, in the case of the comments, the value was assigned as another state. Take a look:

const [newRecipe, setNewRecipe] = useState({
    img: "",
    video: "",
    name: "",
    source: "",
    author: "",
    mealtype: "",
    preptime: "",
    cooktime: "",
    servings: "",
    ingredients: [],
    instructions: [],
    comments: commArr
});

From here, I made all of the single string inputs controlled by one function to update the values for those items in the newRecipe state. I had to be a little creative with the ingredients and instructions, because recipes don't have a set number of ingredients or instructions to include in a form like this. I couldn't just throw in 5 inputs for ingredients and 5 inputs for instructions. I wanted to be able to click a button and add a new input that would then be included in the new recipe's state. To do this, I wrote a function that would update a state array that simply had numbers in it that would act as my keys later on.

const [numIng, setNumIng] = useState([0, 1, 2, 3, 4]);

function handleAddIng() {
    const newNum = numIng.length;
    setNumIng([...numIng, newNum], () => {});
};

Once I had that functioning properly I took that state array and mapped it to render one input for each value in the array, using the value as a key. Once the state array updates with a new number, a new input is added to the page with a proper key, className and onChange function for the input to be controlled.

{numIng.map((num) => {
    return (
        <div>
            <input type="text" key={num} className="add-ingredient" onChange={handleIngredients}></input>
        </div>
    )
})}

Then, to make sure these inputs are also controlled and are being stored in the new recipe state object, I wrote a function to keep the array updated. I had to keep in mind that retrieving elements this way gives an HTML collection, and not an array that I can iterate through in the way I wanted, so I used a spread operator to convert the data from a collection to an array that I could use. I then filter out any of the inputs that don't have any text in them and store the resulting array in the new recipe state object.

function handleIngredients() {
    const ingElements = document.getElementsByClassName("add-ingredient");
    const convIng = [...ingElements];
    const newIngArr = convIng.filter((ing) => ing.value.length > 0).map((ing) => ing.value)
    console.log(newIngArr);
    setNewRecipe({...newRecipe, ingredients: newIngArr});
}

Recipe Manager 2.0 is now functioning the way that I want it to - at least for now. In the future I plan on adding functionality that will display recipes based on an ingredient search, rather than only searching by recipe name. I would also like to filter by tags and include embedded videos from the recipe's author if one is available.

My Recipe Manager Project

loren-michael — Mon, 07 Feb 2022 17:22:42 +0000

Today I wrapped up working on my first project. I decided to make a recipe manager that can help me with meal planning every week. The basic concept is that I can use this site to enter in recipes with forms for their ingredients, instructions, where it came from, etc... and have them all get stored in my own database to pull up later.

Figuring out a database

First I had to figure out a database. I referenced some free recipe API's on the internet, but for my vision there was just too much information and it felt too bulky. Instead, I created my own json file and figured out exactly what information I wanted to be able to store. I started with basic things like the name of the recipe, the link where I found it, an image, ingredients and instructions. Knowing what information I wanted to save, I created a form on the site to allow me to input all of this information. Then I wrote a function that creates a recipe object when the form is submitted, then that recipe object gets posted to the database. Here is an example of one of the recipe objects:

{
      "img": "https://www.rabbitandwolves.com/wp-content/uploads/2018/07/DSC_0872.jpg",
      "video": "",
      "name": "Vegan Caesar Pasta Salad",
      "source": "https://www.rabbitandwolves.com/caesar-pasta-salad-vegan/#recipe",
      "author": "Lauren Hartmann",
      "mealtype": "Side",
      "preptime": "10 mins",
      "cooktime": "30 mins",
      "servings": "6",
      "instructions": [
        "Cook your pasta according to package directions. Drain and let cool. ",
        "Make the dressing. Add all the dressing ingredients to a blender. Blend until smooth, taste and adjust seasoning. ",
        "Once the croutons are done, in a large bowl, add the chopped romaine, pasta, croutons and then pour the dressing on and toss. Serve immediately. "
      ],
      "ingredients": [
        "1/2 C. Vegan Mayo",
        "2 tsp. Dijon mustard",
        "1 Tbsp. Capers",
        "Juice of 2 Lemons, about 2 Tbsp.",
        "2 Tbsp. Nutritional yeast",
        "1 Clove Garlic",
        "1/4 tsp. Salt",
        "Pinch of black pepper",
        "1 Head Romaine, chopped",
        "16 oz. Pasta"
      ],
      "comments": [
        "Omitted the crouton portion of the recipe as we don't make them.",
        "Mini penne is perfect",
        "We don't use nutritional yeast in our dressing, and only use half a lemon."
      ],
      "id": 17
    }

Rendering is fun!

In many places, I encountered the need to iterate through arrays, including the recipes themselves. As an example, I decided to use some forEach loops to render the recipe names in a list:

function renderAllRecipes(recArr) { recArr.forEach(renderOneRecipe) }

Of course, the renderOneRecipe is much more involved, but this was a powerful way to be able to iterate through each of the items in my database and simply pick out the name of the recipe to display it as an option. Now, when our page loads, we see this:

Remember when I mentioned that the renderOneRecipe function was a little more involved? Well, I had to make sure that I was not only displaying the name of the recipe as the inner text of my list item, I also set the id of each of them to the id number of the recipe and added an event listener so that you can click on them to load the entire recipe. I use the id number set from the original fetch to fetch the entire recipe card and display each of the relevant elements on the page in a meaningful way. I made sure that my images would be the same size, I made sure that credit was given and source links provided for each recipe that I use from somewhere else on the web, and I iterated over any arrays in my recipe object to display lists where they're needed.

Getting around without reloading

I also wanted to build some navigational functionality, but without having to reload the page to go between recipes and details. I was able to use two different methods to demonstrate this. For one, I use part of my function to change the display parameter of an element from inline-block to none and vice versa. These two lines of code look like this:

recListSec.style="display: inline-block";
and
recListSec.style="display: none";

The other method I used to hide elements was by assigning or removing the "hide" class to things I wanted to be hidden. These lines looks like this:

selectBar.classList = "hide";
and
selectBar.classList.remove("hide")

Now, when we go back and forth between the index view and a recipe details view, we don't see things that aren't relevant to the details view.

Form building

Now to tackle some forms. I wanted to create a way to enter in all of the information I need for a new recipe. Things like "recipe name" and "servings" are pretty straightforward, but every recipe is different. How do I know how many ingredients are on the list? How many steps are there? Instead of filling up the page with empty boxes, I decided to make a button that would give you a new text box so you never have more than you need. (Don't worry if you hit it too many times, I have a solution for that too!) From there, I wrote a function called createNewRecObj that takes the information from the form and enters it into a new object that then gets sent to a fetch method to POST it to the database. Here is the createNewRecObj function:

function createNewRecObj (e) {
    e.preventDefault();

    // Ingredient array
    let ingArr = [];
    let ingColl = document.getElementsByClassName("add-ingredient");
    for (let i = 0; i < ingColl.length; i++) {
        if (ingColl[i].value.length > 0) {
            ingArr.push(ingColl[i].value)
        }
    };

    // Instruction array
    let instrArr = [];
    let instrColl = document.getElementsByClassName("add-instructions");
    for (let i = 0; i < instrColl.length; i++) {
        if (instrColl[i].value.length > 0) {
            instrArr.push(instrColl[i].value)
        }
    };

    // Comment array
    let commArr = [];
    if (document.getElementById("init-comm").value.length > 0) {
        commArr.push(document.getElementById("init-comm").value)
    };

    // Create the new recipe object that will get sent to the database
    let newRecObj = {
        img: document.getElementById("add-img").value,
        video: document.getElementById("add-video").value,
        name: document.getElementById("add-name").value,
        source: document.getElementById("add-source").value,
        author: document.getElementById("add-author").value,
        mealtype: document.getElementById("add-meal-selector").value,
        preptime: document.getElementById("add-preptime").value,
        cooktime: document.getElementById("add-cooktime").value,
        servings: document.getElementById("add-servings").value,
        instructions: instrArr,
        ingredients: ingArr,
        comments: commArr
    }
    postNewRecipe(newRecObj);
}

Looking into this code a little more, we can see that I'm making three arrays. Looking at the ingredient array, we can see that I am finding each of the text boxes being used for the ingredient list, using a for...of loop to iterate through them, and also looking at the value length to make sure that I'm not adding an empty string to my array.

Then, we simply take each of the form inputs and assign them to their proper key in the object, and send them off to my postNewRecipe function with the newly made recipe object as the argument.

To post, we fetch our resource, tell it we're making a POST with content-type of application/json, and in the body of our POST, stringify our recipe object. This will add our new recipe to the database, and the page will revert to displaying the recipe list with our newly added recipe included.

Moving forward and a note on accessibility

Obviously, there were many other features added to this project and I don't want to nitpick over each and every one of them. I plan on continuing to work on this to add more functionality in the future. If you noticed in the original recipe database item at the top, there are some other tags that aren't used quite yet, like "video embed" and "tags". I would like to find a way to use those things in future versions of this project.

I also am learning the importance of making things as accessible as possible. There are parts of this project that are not as accessible as they could be, so I plan to update them as I learn more about javascript to demonstrate that I am able to consider users of all abilities who might like to use this project moving forward.

Thank you for looking over my project! Make sure you check it out in the future for new versions!

Rendering: Half-Full or Half-Empty?

loren-michael — Thu, 06 Jan 2022 20:41:21 +0000

Today I was working on a lab for my Flatiron courses and noticed a note:

"Pessimistic rendering is recommended."

Well what the heck does that mean? Is my program feeling low? Down? Defeated? (Sometimes I do when I hit a snag, but that's no reason for the program to feel that way...)

I quickly learned that there are two different forms of rendering:

Pessimistic
Optimistic

In today's world of instant gratification, users generally don't want to wait for anything to load. It's understandable - with fast internet and apps that are designed for delivering information fast, we've just gotten used to it. When you are coding, it's smart to keep this in mind, because often you will discover changes you can make that will update your DOM but won't necessarily require you to reload/refresh your entire page. This kind of rendering is referred to as Optimistic, because it assumes that the server will update the database with the new information and doesn't depend on having to go through another load and fetch and render to display the new information. It simply says, 'oh, I see that you like this. I trust my program will update the database for you, so I'll just mark down your like really quick so you can continue browsing."

On the flip side, the pessimistic way of rendering these changes involves the rigmarole of sending a patch, reloading the page, fetching the new data, rendering everything all over again... it's not very trusting of your program and though it might not take a very long time, any time spent reloading might allow the user a moment to turn their attention elsewhere.

Optimistic rendering is obviously more desirable if you're trying to keep the user's attention on your program, but there are pros and cons to each style. Optimistic approaches work best with pretty simple tasks - tasks like "liking" things. When you get into more complicated tasks, like filling out forms or making a purchase, that's when you need the functionality of pessimistic rendering. It will be more accurate and dependable than making a visual change and hoping that it saved in the back-end.

innerText vs textContent

loren-michael — Wed, 08 Dec 2021 22:19:26 +0000

As I was going through some lessons about manipulating the DOM, we were presented with two ways to change the text of a node (or, more commonly, an HTML element):

.innerText
and
.textContent

While their functions appear to be similar - take the text in an node and change it to something else - they actually work pretty differently when taking a closer look.

Let's start with .textContent

From what I've learned so far, this method will return the text in a node while also taking spacing into consideration. It will give you all of the raw text inside the node, including some text that might be hidden from users. It also can be used on all node objects.

Moving on to .innerText

When you use .innerText, you will have returned to you only the text inside the node returned to you without any additional spacing included. It will only give you the visible text that gets shown to users. Interestingly, because of the way that .innerText takes the extra computing time to look at the layout, it can feel sluggish and is more demanding on your system.

Looking at them side by side, it seems that using .textContent is generally the habit you want to create when you're changing some text in your DOM.

Oh, and I haven't really learned about .innerHTML yet, but maybe when it comes up I'll revisit and compare all three together.

Knowing Where to Start

loren-michael — Wed, 01 Dec 2021 18:45:51 +0000

I've discovered as of late that knowing where to start is half the battle.

When I am approaching a function I need to write for a lab, I can think of the different methods I need to use to complete the assignment, but I struggle a lot with knowing where to start. I might try working backwards for a change, starting with defining what I need to see in my output and working back from there.

Has anyone else faced this kind of hurdle? How did you overcome it? Practice, practice, practice?

Note Catch-up

loren-michael — Mon, 29 Nov 2021 16:57:40 +0000

Over the Thanksgiving holiday I traveled and didn't have access to my desktop computer (I know, I know - who has a desktop anymore?) so I spent a little bit of time going back through some lessons and making notes using VSC. It helped my understanding tremendously to go back and type functions out myself. Running the notes is not possible, because I like to practice and see the progression of functions and sometimes that involves assigning the same variable multiple times. But these notes are not meant to be functional, they are meant to give me a well organized way to return to a concept and review it quickly.

I highly recommend making files of notes as you're learning, it helps quite a bit with the more complicated concepts.

Note Taking 101

loren-michael — Fri, 12 Nov 2021 19:11:33 +0000

While going through Flatiron's Pre-Work and part of Phase 1, I've been taking notes in a Moleskine. While it's my favorite way to retain information (I learn well by writing things down in my own handwriting) it definitely leaves much to be desired. Writing out JS by hand is a pain if you're trying to show yourself examples of the concept you're studying. It takes up a lot of paper very quickly with how many lines it takes up, and the hand cramps!

I've started to experiment with different ways to take notes while going through class. My newest method will be to keep notes organized in .js files that give examples of how different functions work. The latest concept I've gone over are Arrow Functions, so I built a file that shows progression from a regular function to a function expression then to an arrow function. It came in handy while doing my lab work, so I will likely continue this to see if it is helpful with more complex concepts.

Long term I'm hoping it will be a go-to resource of my own notes and code examples so that when I come across these concepts later on I have a file that I can go to if I'm having trouble.

The journey begins...

loren-michael — Tue, 09 Nov 2021 17:55:56 +0000

In the last couple of days I finished up the Software Engineering course pre-work for Flatiron School. I feel like my basic knowledge of HTML, CSS, JavaScript has expanded but it also feels like I've only just scratched the surface.

In the coming weeks I'll be juggling course work with the holiday season. This means converting to using my laptop to do work at my mother's house while visiting for a couple of weeks over Thanksgiving. I'm hoping that I will be able to build out my own basic website very soon, and that as I learn more I'll be able to update it with new and exciting features.

I hope to make blogging a regular part of my learning process going forward, both to keep track of my own progress and show others how easy it is to pick up new skills. I'm coming to this at age 36, just left an old career because of covid-19 based anxieties (I was a production manager and live sound engineer at a venue here in Chicago) and wanting a lifestyle change.