Forem: peabody00

React, Flatiron Mod 5 Project, Part 2

peabody00 — Tue, 07 Dec 2021 18:59:02 +0000

Where were we?

In my last blog post I was trying to explain in my limited, beginner understanding how Redux works in React. I had gone over how Redux takes the store out of the components and centralizes it. This gives the ability to access the store from any component.

Now what?

Having access to the state from anywhere is great and all but what about making changes to the state. There needs to be ways to change the state based on user interactions. This is where actions and reducers come in.

One of the functions that comes with creating the store this way is dispatch(action). Dispatching an action is the only way to trigger a change in the state.

An action is simply just a JavaScript object with a property of type. Here is a very basic example.

const increaseCount = { type: 'INCREASE_COUNT' }

This action could be called something like this.

this.props.dispatch(increaseCount)

Dispatch sends this action to the reducer to then alter the state. A reducer is a function that takes an action and returns the new state. The action describes what is happening and it is the reducer's job to return the new state based on the action.

For the above example, a simple reducer might look like this.

function reducer(state = {
  count: 0,
}, action) {
  switch (action.type) {

    case 'INCREASE_COUNT':
      return { count: state.count + 1 };

    default:
      return state;

  }
}

Here the initial state is set as 0 and calling dispatch with increaseCount as the argument tells the reducer to run the action type of 'INCREASE_COUNT'. It then returns the new state which is the old state +1.

The switch case format is a standard one that allows you to have other ways to alter the state. The reducer knows which case to use by the action type given to it.

This is obviously a very simple example and things can get really complicated quickly. As a beginner though, I am trying to keep it simple to not confuse myself, much less others.

What about Thunk?

Thunk is a middleware that can be used with our Redux store. Thunk lets you call action creators that return a function instead of an action object. That function receives the store's dispatch method, which is then used to dispatch regular synchronous actions inside the function's body once the asynchronous operations have been completed (ref).

The reason this is needed is for apps that need to communicate with an API or perform side effects. In my project I have a an API to get movie data as a well as a Rails backend that saves information from my app. For both of those I am making fetch calls to get information. Fetch is an asynchronous function so when Redux is running things synchronously you can run into issues.

Thunk is a way to make sure that promise that fetch gives back gets resolved before continuing code execution. Here is an example from my movie project.

export function fetchMovie(movie) {
    return (dispatch) => {
        fetch(`${apiURL}${movie}?api_key=${MY_API_KEY}`)
        .then((resp) => resp.json())
        .then((movie) => dispatch({ type: 'SEARCH_MOVIES', payload: movie}));
    };
}

Instead of my action passing an object, I am returning a function that dispatches my 'SEARCH_MOVIES' action type with the payload of the movie information I got back from my fetch call. That tells the reducer I have set up how to alter the state. In this case I am making the movie in my store be the one that is was just searched.

With all that information, we can now see the flow of how actions interact with the centralized state as well as seeing the need of middleware like Thunk to help as we use APIs to add more functionality to our web apps.

I am not sure how helpful any of that is but I know I benefitted from getting the chance to spend more time going over the lessons I had about Redux as well as searching online for more information.

React, Flatiron Mod 5 Project, Part 1

peabody00 — Mon, 06 Dec 2021 20:40:12 +0000

Of the 5 modules for Flatiron School (Ruby, Sinatra, Rails, Javascript, and React), I think I have found this one the most difficult to wrap my head around.

I can definitely see the benefits of React. It's approach of focusing on clean user interfaces using components that are aware of state and able to re-render only the parts that are needed is very powerful.

I found myself getting lost when, on top of learning all this stuff for React, they throw in Redux and Thunk as new concepts and code to learn about.

In a lot of ways I feel like I am limping across the finish line as I come to the end of my time with Flatiron.

Here is a link to my project if you are interested.

Important Lessons

Since I struggled so much with Redux and Thunk, I am splitting my blog post in two parts to go over each idea in the hopes that it will sink some of the concepts deeper into my mind. Redux does make more sense to me than Thunk and hopefully I am able to explain it well enough.

Redux

Redux seems to be about taking much of the logic out of the React components and moving it elsewhere so that the components can focus on presenting data and letting the user interact with the app.

Redux moves the application's state out of the components to a central store of data. This makes it so every component that needs access to the store data can get it more easily.

This isn't going to be a tutorial about how to set up Redux. There are plenty of those online. I would recommend the Redux documentation for in depth explanation of setup and ideas. This is more about going over the main concepts of Redux.

With that in mind, if the state is now outside of the components then it needs to exist. Here is the code from my index.js file.

import React from 'react'
import ReactDOM from 'react-dom'
import { createStore, applyMiddleware } from 'redux'
import { Provider } from 'react-redux'
import thunk from 'redux-thunk'
import rootReducer from "./reducers/rootReducer"
import { composeWithDevTools } from 'redux-devtools-extension'
import './index.css'
import App from './App'
import { BrowserRouter as Router } from 'react-router-dom';



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


ReactDOM.render(
  <Router>
    <Provider store={store}>
      <App />
    </Provider>
  </Router>,
  document.getElementById('root')
)

The important parts here are the createStore function, the rootReducer file, and <Provider> tags. My variable store is what is created when the function createStore runs. The rootReducer file takes in my reducer functions which are responsible for returning the next state tree, given the current state tree and an action. More on that later.

The app now knows about the store and how the store gets changed based on actions. What it needs is to make that store available to the components. That's where the <Provider> comes in. By Wrapping the <App /> component in the <Provider> and giving it the store, we give every child component of <App /> the ability to access the store no matter where they fall in the hierarchy of components.

To connect one of my components to the store, I can use something similar to this code.

import { connect } from 'react-redux'

...

const mapStateToprops = (state) => {
    return{
        movie: state.movies,
    }
}
export default connect(mapStateToprops)(MovieCard)

This now adds everything that is in my store under movies as props to my component with the key of movie:. So in this component I can now display the current state. My project, where this code is from, searches an API to return movie data. So in my component I can display things now like {this.props.movie.title}.

Actions & Reducers

That brings us to how we can change the store data. I will save that explanation for part 2 where I can also talk about Thunk and how it works into all of this.

Thanks for reading.

Javascript, MOD4 Project

peabody00 — Fri, 24 Sep 2021 17:04:14 +0000

This module has been a roller coaster ride. I enjoyed many parts of Javascript and can see the lessons I learned all throughout the modern Internet.

As I approached my project for this module I wanted to do something that I was excited about and lined up with my interests. So I chose to make a simple pixel art web app. As simple as it sounded in my head it turned out to be much more difficult to create.

I learned a great deal making this project but I wanted to focus on one important lesson I learned.

Here is a link to my project if you are interested.

Important Lesson

One of the big lessons I learned is when I tried to create a drawing tool that is pretty standard in any drawing app. It is the flood fill tool. The idea is to click inside an enclosed area and have it fill with the selected color.

This lead me to the concept of Recursion. In the most basic sense, recursion is a function that calls on itself until a condition is met. Once that condition is met the function stops running. Here is an example (the information that follows comes from javascript.info).

Here is the recursive function.

function pow(x, n) {
  if (n == 1) {
    return x
  } else {
    return x * pow(x, n - 1)
  }
}

pow(2, 3) // 8

This function takes x and multiplies itself n times or x to the power of n. It does this by first checking if n == 1. If it does, it just returns the number x because a number to the power of 1 is just the number. If n does not equal 1 then it returns x * pow(x,n-1). It keeps calling this function until n == 1 and then returns the final value.

There is obviously much more to it. But this is about the level of my beginner brain. For a more in-depth explanation please visit this page.

How does this relate to my tool?

My implementation of a pixel art app uses table cells and changes their background color. For the flood fill to work I need to check what the value of the background color is to cells adjacent to where I click. If their background color doesn't match my current color, it changes the color and moves on to the next cell. Sounds like a good case for recursion. Here is the code I used (Not all my code. A lot of research went into it).

function fillBucket(sr, sc, newColor, targetColor, current) {
    if (grid.rows[sr]) {
        current = grid.rows[sr].cells[sc]
    }

    if (sr < 0) {
        return
    }

    if (sc < 0) {
        return
    }

    if (sr > gridHeight.value - 1) {
        return
    }

    if (sc > gridWidth.value - 1) {
        return
    }

    if (grid.rows[sr].cells[sc] !== current) {
        return
    }

    if (current.style.backgroundColor === targetColor) {
        current.style.backgroundColor = newColor
    } else {
        return
    }

    fillBucket(sr - 1, sc, newColor, targetColor, current);
    fillBucket(sr + 1, sc, newColor, targetColor, current);
    fillBucket(sr, sc - 1, newColor, targetColor, current);
    fillBucket(sr, sc + 1, newColor, targetColor, current);
}

It basically checks the 4 cells around where the user clicks (up, down, left, right) and changes the color if it doesn't match. This is a slow method of accomplishing this. It requires a lot of checks. So if the area to fill is big, it can slow down. There are other recursive methods that can do this more quickly but I was already swimming in deep waters and didn't want to confuse myself more.

Conclusion

It was difficult to get this working but it did teach me an important principal and gave me more depth as a programmer. It certainly helped me appreciate the thought that goes into programming a seemingly simple feature.

Ruby on Rails, Flatiron Mod3 Project

peabody00 — Wed, 12 May 2021 01:08:57 +0000

Ruby on Rails

Module 3 for Flatiron School builds on the previous lessons of Sinatra and ActiveRecord.

Project Idea

I decided to do a simple college website for my project. I call it Chesapeake Clown College. The idea is that two types of users (teachers and students) can log into the website and manage different things. A teacher login can create new courses and activities for the student. The student login can look at the courses and assign them to their schedule. They can also join different activities.

Here is a link to the project.

Important Lesson

I think one of the biggest lessons I got from this module involves how Rails makes routing much easier. With Sinatra the routes had to be explicitly stated in the controllers for things to run properly. Rails simplifies this by declaring all the routes in a file called routes.rb.

The routes can be described in several different ways in this file but the easiest way is to simply declare resources for the different models.

Rails.application.routes.draw do
  get '/login' => 'sessions#new'
  post '/login' => 'sessions#create'
  get '/teacherlogin' => 'sessions#teacher_new'
  post '/teacherlogin' => 'sessions#teacher_create'
  post '/logout' => 'sessions#destroy'
  get '/auth/:provider/callback' => 'sessions#omniauth'
  root 'welcome#index'
  resources :activities
  resources :courses
  resources :schedules
  resources :students_activities
  resources :teachers do
    resources :courses
    resources :activities
  end
  resources :students do
    resources :schedules
    resources :students_activities
  end
  resources :sessions
end

This is the code for the routes.rb from my project. I don't know if it's perfectly correct but it works in my project.

The advantage of declaring routes this way is that resources :activities allows Rails to know the routes for the Activities controller automatically.

Running rails routes gives us this result for Activities.

       Prefix Verb   URI Pattern                          Controller#Action
   activities GET    /activities(.:format)                activities#index
              POST   /activities(.:format)                activities#create
 new_activity GET    /activities/new(.:format)            activities#new
edit_activity GET    /activities/:id/edit(.:format)       activities#edit
     activity GET    /activities/:id(.:format)            activities#show
              PATCH  /activities/:id(.:format)            activities#update
              PUT    /activities/:id(.:format)            activities#update
              DELETE /activities/:id(.:format)            activities#destroy

With just the simple declaration of resources :activities all RESTful CRUD routes are created for me.

This also creates helper methods that can be used in my code. If I need to link a route I just take the prefix from above and add _path to it to create a link. activities_path will take me to the INDEX route for activities. It is a simple yet elegant way to manage routing.

Conclusion

Rails works magic in so many different areas but the routes are one area that it really shined for me. As overwhelming as this module was, I feel I came away from it with some good lessons.

Module 2 Sinatra Project for Flatiron School

peabody00 — Mon, 08 Mar 2021 00:51:00 +0000

Sinatra Project

This module has been a much different experience than the last one. In this module there were so many more concepts that we learned that I felt much more uncertain of what I was learning. The project has helped deepen my understanding of the concepts but I still feel like I am just barely scratching the surface. Luckily I have a few individuals that I rely on for support both technical and emotional (Thanks Evelyn and Jenny).

Here is a link to my project.

Project Idea

I struggled a lot more this time with my project idea. It changed a few times as I thought more about what was required of me and what I thought I could accomplish.

I finally settled on creating a simple trading card game. The basic idea is to collect cards to increase your Life score compared to other players. The interface allows a player to view their collection and open new card packs. There is a messaging area where players can post messages on a wall for all to see. A player can always edit and delete their own posts. There was a planned trading card feature that requires more work that I will talk about later.

Important Lessons

I learned many concepts while making this project but the biggest lesson came from ActiveRecord associations. I used some of the simpler associations during the course but learned about many other ways that ActiveRecord can associate models. My project uses 5 models User, Card, Post, UserCard, and Trade.

Some associations were simple. A user has many posts, a post belongs to a user. Others got more complicated, a user has many cards and cards have many users. A usercard model was needed to join the other models so a usercard belongs to both users and cards.

As I thought through the unfinished trading feature the association became more complicated and unfamiliar. The way I tried to implement it was suggested by a coding partner. It involved using an alias and a foreign key to help identify both users and both cards in a trade.

class Card < ActiveRecord::Base
    has_many :user_cards
    has_many :trades
    has_many :trades, :foreign_key => "other_card_id"
    has_many :users, through: :user_cards
end

class Trade < ActiveRecord::Base
    belongs_to :user
    belongs_to :other_user, :class_name => "User"
    belongs_to :card
    belongs_to :other_card, :class_name => "Card"
end

However the more I thought about it that didn't seem to be the right relationship. It occurred to be that a users collection of cards existed in the usercards table of the database. If that is the case then a trade needed a belongs to, through relationship. That doesn't seem supported in Sinatra as I researched it. There is a has one relationship that I need to research more but time was running out for my project.

I ended up making sure the features I had in program met all the requirements so I could turn that in. My plan is to work more on a trade feature before my project review.

Final Thoughts

I understand how things are building as I progress through my Flatiron Software Engineering course. Sometimes it is hard as we learn the fundamentals knowing that later tools will make doing what we are doing now easier. For now I will do my best to learn the material and enjoy the ride.

CLI Project for Flatiron School

peabody00 — Sun, 10 Jan 2021 23:05:32 +0000

Module 1 Project

As I have been working these past two months through the Flatiron Software Engineering program, I barely had time to consider anything else aside from the daily labs and instruction I was receiving. It seemed like everything was about getting a lab to run properly so there were no failures. That took trying to decipher what was being asked of me (which sometimes wasn't very clear).

As I have approached my Module 1 project, things changed when I was writing code. I was solving my own problems and it made me feel different about my code. It gave me the freedom to solve problems in my way, not necessarily the way a lab was asking me to. It was a good feeling.

Project Idea

When I was considering what I should do for my project I went through several ideas. I was watching videos showing projects being made and I was reading ideas about what a project might entail. The idea that I settled on is a Mad Lib Creator & Dictionary.

In my mind, this seemed like a fun idea but one that would challenge my limited coding knowledge.

Big Lesson

The first challenge I had to overcome was just getting started. The blank screen can be very intimidating. One thing that helped me was a video from Avi Flombaum, one of Flatiron's founders. In it he described how to create a Ruby Gem. In that video he said we wanted to "write the code I wish I had." He said this many times and I took that to heart.

I started with the file I wanted people to use to run my CLI program. ./bin/madlib started very basic with puts "Hello World".

From there I stepped through each part of the program and created things as I needed. I was always able to test things as I went because I started with the first thing a user would use. In this way my framework for my program was built from the ground up. It was able to support where I wanted to eventually get to with my program because I laid the groundwork for it in the beginning.

Overview

My program ended up with 5 classes of objects CLI, API, and a class for each of my Mad Libs. Each class was responsible for a different portion of my program. The CLI class is the menu that guides the user around my program. The API class was how my program interacted with the dictionary API that I used to find and validate words and the 3 Mad Lib classes are the individual Mad Libs that were created for users to interact with.

Other Big Lesson

The other big issue that I had to work through came when I was trying to interpret the data I was receiving from my API. The API was helpful in that it gave me Ruby code to help create my connection.

url = URI("https://wordsapiv1.p.rapidapi.com/words/word)

http = Net::HTTP.new(url.host, url.port)
http.use_ssl = true
http.verify_mode = OpenSSL::SSL::VERIFY_NONE

request = Net::HTTP::Get.new(url)
request["x-rapidapi-key"] = API_KEY
request["x-rapidapi-host"] = 'wordsapiv1.p.rapidapi.com'

response = http.request(request)
puts response.read_body

The puts response.read_body looked like a hash but wouldn't work like a hash. It didn't click until I was looking through some notes and remembered that the API data came in as JSON and needed to be parsed by Ruby. Once that clicked, working with my API became much easier. Another big help with that was the Ruby gem Awesome Print. Making my objects more readable was a big step towards seeing the data that I needed to pull out from my API calls.

Favorite Feature

One of my favorite features of my program involves a validation I created for the words that users can type into the Mad Libs. I wanted to make sure if the program asked the user for a noun that the word the user typed in had to be a noun. It took several steps and versions but this is the code I created.

def valid_partofspeech?
    if @word.include? " "
        false
    else
        @url_combined = URI(URL + @word + "/definitions")
        self.connection(url_combined)

        part_array = []
        if @word_hash["success"] == false
            false
        else
            word_hash["definitions"].each do |def_hash|
                def_hash.each do |var1, var2|
                    if var1 == "partOfSpeech"
                    part_array << var2
                    end
                end
            end
        end
        part_array.include?(part_of_speech)
    end
end

The first part of the validation, if @word.include? " " checked if the user had a space in the word they typed. If that happened then the validation returned false. The next step took the users input (which is created in the Mad Lib class) and made sure the API call was successful, if @word_hash["success"] == false. If the user misspelled a word or typed in gibberish the API endpoint "success" would be false. If that happened then my the validation would return false. Finally if all the user's input worked past those validations the API would look up the user's word, take out the "partOfSpeech" endpoint and put it in an array, and then check that the part of speech the the Mad Lib needed was included in the array that held all the parts of speech.

In that way, I could be sure that one of the definitions of the the user's word matched the part of speech needed by the Mad Lib.

Conclusion

This whole project ended up as a big boost to my confidence when it came to coding. Doing the labs and the classwork always made me feel like I was behind or not understanding the topics we were going over. Having completed my Module 1 project though has shown me that the lessons have sunk in and that even if I do run into a problem I can do the research and figure out what I need to do. I am grateful to my instructor and the others that have helped me through this first section of my course.

Why did I decide to study Software Engineering?

peabody00 — Mon, 23 Nov 2020 02:24:51 +0000

:001 > puts "Hello World!"
Hello World!
=> nil

I recently joined Flatiron School in their Software Engineering program. The first two weeks of the course are called the First Mile. As part of that I was tasked with writing a blog post to answer the question above.

As I think back to where my journey with coding first started, I go back to Christmas of 1984. I was almost 6 years old and my family got a Vic20 as a present.

I remember being excited to have such a cool and wonderful piece of technology available to me. I remember opening the manual and finding instructions on writing small programs in BASIC. I would work slowing typing those instructions into the interface. Often I would have something off in my syntax and have to re-type everything and hope I got it right. If I did I was rewarded with a sound or some colors and it was an exciting feeling for a six year old.

Since then I have been interested in technology in many different ways. I never got much deeper into coding but I was into computers and the internet and everything tech related.

Over the years I tried to get into coding with various levels of success. Coding always seemed to me like magical powers and the people who could use it like wizards. It was mysterious and the wizards had their own language to keep away outsiders. I wanted that power but never really had the time while working and having a wife and kids.

It finally got to the point where I was offered an opportunity by some family to really throw myself into it. I decided it was time.

These past two weeks have been a roller coaster. I felt confident in the first week and felt like I was understanding what was presented. In the second week there were some hard days where I was asking myself "WHY did I decide to study software engineering?"

The breakthroughs and successes have carried me through. I still know there is so much to learn and I know it will be complex and hard at times. I feel like with the support of my family and my online classmates that I can do this.

Thanks for reading.