DEV Community: JesseNReynolds

React Class vs Functional Components, Part 3: Lifecycle Methods

JesseNReynolds — Fri, 30 Apr 2021 23:09:56 +0000

Bad news; There's not exactly a one-to-one comparison here. Functional components have access to useEffect, which can give us most of the functionality we got from methods like componentWillUpdate, componentDidUpdate, componentDidMount, componentWillUnmount, etc, but it's not quite the same.

The basics

If you want to make use of useEffect, you'll need to import it (it's a named export of React). useEffect takes a callback function and an optional array. This could be:

useEffect(() => console.log('You can define in line'))

const someFunction = () => {
  console.log('You can pass a function')
}

useEffect(someFunction)

These examples will call the effect every time the component renders or rerenders. This could be costly, if we don't want to call the effect every time, we need to pass a dependency array

Dependencies

If we only want to call the effect after the initial render, we can pass an empty dependency array to the hook.

useEffect(someFunction, [])

We can also have useEffect call the effect whenever certain things change by adding those values or references to the dependency array.

const [name, setName] = useState('')
useEffect(someFunction, [props.someValue, name])

In the above example, we will call the effect someFunction on initial render, as well as when the value of either props.someValue or name changes.

Cleanup

We might have effects that require cleanup, for example an asynchronous function or subscription. In this case, we need to make sure to include a cleanup function.

const [name, setName] = useState('')
useEffect(() => {
  someFunctionThatWillNeedCleanup()  
  return someFunctionToDoCleanup()
}, [props.someValue, name])

For more information about effects and cleanup, visit the Effects with Cleanup section of the react docs.

React Class vs Functional Components, Part 2: State

JesseNReynolds — Fri, 23 Apr 2021 19:56:24 +0000

State

In the before times we only had access to state methods in class components, and a controlled form for first and last name looked like this.

class OurComponent extends React.Component {
  constructor(props) {
    super(props);
    this.state = {
      givenName: '',
      surName: ''
    };
  }

    handleGivenNameChange = event => {
    this.setState({
      givenName: event.target.value
    })
  }

  handleSurNameChange = event => {
    this.setState({
      surName: event.target.value
    })
  }

  handleSubmit = event => {
    //not relevant here, nothing will change in the body of 
    //this function unless you're dealing with a callback  
    //that references state or props
  }
  render() {
    return (
      <form onSubmit={this.handleSubmit(event)}>
        <input type="text"
        onChange={event => this.handleGivenNameChange(event)} 
        value={this.state.givenName} />
        <input type="text"
        onChange={event => this.handleSurNameChange(event)} 
        value={this.state.surName} />
      </form>
    )
  }
}

But now we can use hooks to write functional components that are stateful. We need to import useState, and the we set one or more state variables to track state, and and a name for the function to update the state. Those variables can be directly referenced, and we can call the function to set the new value.

import React, { useState } from 'react';

function OurComponent(props) {

    const [givenName, setGivenName] = useState('')

    const [surName, setSurName] = useState('')

    const handleGivenNameChange = event => {
      setGivenName(event.target.value)
    }

    const handleSurNameChange = event => {
      setSurName(event.target.value)
    }

    const handleSubmit = event => {
      //not relevant here, nothing will change in the body of 
      //this function unless you're dealing with a callback  
      //that references state or props
    }

    render() {
      return (
        <form onSubmit={event => handleSubmit(event)}>
          <input type="text"
          onChange={event => handleGivenNameChange(event)} 
          value={givenName} />
          <input type="text"
          onChange={event => handleSurNameChange(event)} 
          value={surName} />
        </form>
      )
    }
  }

We haven't reduced our number of lines by that much, but we have made everything more compact; referencing givenName is certainly more concise than referencing this.state.givenName. In fact, now that our variables are more terse, we could do a little refactoring here that would have left some longer, hard to read lines in the class component...

import React, { useState } from 'react';

function OurComponent(props) {

    const [givenName, setGivenName] = useState('')

    const [surName, setSurName] = useState('')

    const handleSubmit = event => {
      //not relevant here, nothing will change in the body of 
      //this function unless you're dealing with a callback  
      //that references state or props
    }

    render() {
      return (
        <form onSubmit={event => handleSubmit(event)}>
          <input type="text"
          onChange={event => setGivenName(event.target.value)} 
          value={givenName} />
          <input type="text"
          onChange={event => setSurName(event.target.value)} 
          value={surName} />
        </form>
      )
    }
  }

This wouldn't be a good refactor if you were controlling to prevent bad inputs or to do anything complex, but we can see the sorts of refactors that having shorter ways to reference and change state opens up

Come back next week for useEffect, and how it can replace the class based lifecycle methods like componentDidMount, componentWillUpdate, etc.

React Functional vs Class Components Part 1: Props

JesseNReynolds — Sat, 17 Apr 2021 00:17:32 +0000

The Times, They are a Changin'

If you, like me, learned React with class components doing all the lifting you may be wondering what's new with these functional components and their hooks that people are talking about? Maybe when you were learning React the curriculum you were following said to use functional components when you didn't need state or access to lifecycle methods. Now you're looking at React again and people are talking about hooks and how functional components are SO MUCH BETTER. What happened?

In React 16.8, hooks were introduced. Don't worry, though, the stuff you learned about React is still true. There's no big shakeups to how class components work, though you may run into a deprecated method here and there. So don't worry, you didn't just inherit a huge technical debt on that side project you used react for a while back and want to add a feature to now.

React's bread and butter are props and state, we'll address how functional and class components deal with props in this article, then we'll address state, and finally lifecycle methods in their own posts.

Props

Just as a refresher, when you pass props to a class component it might look like...

<OurComponent color={'purple'}/>

Good news, no change there! It doesn't matter if you're declaring a class or functional component, you pass it props the same way.

class Welcome extends React.Component {
  render() {
    return <h1>Hello, {this.props.color}</h1>;
  }
}

In a class component props are handled by the constructor method from React.Component and we reference them with this.props.color..

function OurComponent(props) {
  return <h1>Hello, {props.color}</h1>;
}

In a functional component, we accept props as an argument to the top level function, and can reference the color key in the props object with props.color.

Next week, we'll tackle state! Be excited, because we're going to meet our first functional hooks.

My Experience with Flatiron School

JesseNReynolds — Thu, 25 Mar 2021 22:11:57 +0000

I've now completed my final project review, and am starting to look for jobs. It seems like so long ago and also only yesterday that I started the Flatiron School Software Engineering program. I've learned so much, met some wonderful people, and developed a passion for development and the ability to solve problems and build solutions that I have been able to acquire so far.

The curriculum can be frustrating at points, parts almost seemed out of order. The majority of it, though, is good. Most lessons were well written, with good supplementary information linked in case the student is struggling. The curriculum did a great job teaching concepts, which, I've been told by people I know in the field some bootcamps miss on. It sounds cheesy, but I really do feel the curriculum did a good job of teaching how to think like a software engineer and not just someone who can only regurgitate the patterns they've seen before.

I know a lot of bootcamps have moved to 100% javascript, but I am very happy to have learned Ruby and Rails on the way. Seeing how similar concepts are handled by different languages helps peel back the layers and see the workings with more context. Rails is also an incredibly streamlined back-end for personal projects that I'm sure I'll use again even if I land in a shop with a different stack.

I know that this is just the start of a career, and there's so much left to learn and to explore, but I feel I have been well prepared to continue that exploration on my own, or in the context of a professional team.

In which I Sing the Praises of Redux Toolkit

JesseNReynolds — Thu, 18 Mar 2021 21:52:21 +0000

Using Redux to store data that will be used across components has obvious advantages, but it also comes with some specific (at least potential) drawbacks.

Configuring, accessing, and updating the store all become significantly more dense as the store grows. This leads to an increasingly complex configuration and larger and larger chunks of boilerplate, not to mention the increase in potential for bugs that could become harder to trackdown in a dense and not inherently well managed codebase.

Enter Redux Toolkit.

First let's talk about some bonuses:

Redux Toolkit adds an immutability (courtesy of Immer) layer to take some of the mental overhead out of writing dispatches
Redux Toolkit by default utilizes Redux Devtools to make it easy to view state and its changes during development.

Redux Toolkit makes it easy to configure the store and easy to access and update only the parts of the store that any component needs to interact with. Each top-level segment of the store can be extracted to its own file, and much of the boilerplate can be abstracted away. These segments are referred to as slices. By thinking of each of these as their own mini store, and compartmentalizing them, we can separate the concerns of the various parts of the store and then bring them together easily when we configureStore. Since we can do so without the need for a root reducer, any troubleshooting later is that little bit less taxing.

By bringing convention to the whole system, we can more quickly navigate to the code we're looking for, and make modifications to the codebase with less lines of code and less potential for errors. Those cleaner sections of code will also be easier for other developers to find, understand, and add to later. Our system will be easier to develop with, since we can use Redux DevTools to watch our state.

I realize I haven't shown any references in this post, that's because I could not hope to give a better understanding of using Redux Toolkit than the documentation does by going through a sample project. Please, if you are starting a project and plan to use Redux, have a look at Redux Toolkit. Consider if it's right for your project. The ease of use, scalability, and convenience have absolutely made me a fan.

Iteratively Creating Select Options in JavaScript

JesseNReynolds — Wed, 03 Feb 2021 22:24:37 +0000

I recently completed a Vanilla JavaScript app that charts music in a modified form of the Nashville Number System.

The composition is handled by a form that is a bunch of grouped selects, each measure is divided into two half measures which each have two selects representing interval from the tonic and any character modifications to the chord. The form is generated from a JSON object stored in a database row on my back end, and when modified and saved the form is transformed into a JSON object to be persisted in the same way.

The thing I want to talk about in this article, though, is the selects themselves. As you can see, even in a fairly simple song, there are a lot of them.

And each of them has a lot of options. In the future, the second set of options, the chord modifiers, might well be expanded upon or referenced elsewhere, so we need to make sure that if there's an update to the supported modifiers it's an easy update in our app.

I addressed both concerns (the large list of options, and the probability that list would be added to later) by making each of these lists of options into arrays and then adding them to the selects when the selects are created and appended to the DOM.

const INTERVALS = ["", "1", "b2", "2", "b3", "3", "b4", "4", "b5", "5", "b6", "6", "b7", "7"]
const MODIFIERS = ["", "maj", "min", "maj7", "min7", "maj9", "min9", "dim"]

...

    static buildSelectsFromHalfMeasure(halfMeasure, targetDiv) {
        const intervalSelect = document.createElement('select')
        targetDiv.appendChild(intervalSelect)

        const modifierSelect = document.createElement('select')
        targetDiv.appendChild(modifierSelect)

        INTERVALS.forEach(interval => {
            const option = document.createElement('option')
            option.text = interval
            intervalSelect.add(option)
        })

        MODIFIERS.forEach(modifier => {
            const option = document.createElement('option')
            option.text = modifier
            modifierSelect.add(option)
        })

        intervalSelect.value = halfMeasure["interval"]
        modifierSelect.value = halfMeasure["modifier"]

        intervalSelect.addEventListener('change', Song.addSaveButtonIfNonePresent)
        modifierSelect.addEventListener('change', Song.addSaveButtonIfNonePresent)
    }

For each half measure, we create a div. We append that div to the div that belongs to the measure, and to the half-measure div, we append two selects, then we iterate over our list of intervals and modifiers to populate the options for the selects. If in the future I want to add seemingly bizarre chord modifiers like "13sus4add2" I can do that in one place and know that everywhere I'm referencing all available modifiers, it's been addressed.

A simple MVC group invite feature in rails.

JesseNReynolds — Thu, 07 Jan 2021 05:34:14 +0000

First, a quick introduction

I struggle with these blogs. For those not following along at home, I'm doing a development bootcamp; one of the requirements is to do a technical blog after each milestone project. It's a struggle for me because I've been coding in earnest for all of 3 months now; what could I have to say that anyone would, could, or should care about?

I reached out to some of my friends in the program and asked them to have a look at my project, OpenStage (be patient if it takes a moment to spin up, it's hosted on heroku) and tell me if there was anything they wanted to know about. My friend Bella said she'd like to know more about how I managed the invitations to bands, so that's what this blog will be about. At least I know there's one person who will think it's interesting.

Invites?

Yeah, so my app has a few goals.

Help musicians form bands
Help bands find open stage time to play casual gigs
Help venues draw traffic by having bands play

To have bands, which are made of multiple Muscians (users of class User in my models), you need to be have a join table. There are a number of questions to be asked about how to handle who has privileges in a band, but for this demonstration I decided the user that created the band (the band leader) would have the unilateral power to request gigs and invite members. We'll need a join table so that users can have many bands and bands can have many users, and we've called this join table band_members.

class BandMember < ApplicationRecord

belongs_to :user
belongs_to :band

validates_uniqueness_of :user_id, scope: :band_id
end

class User < ApplicationRecord

has_secure_password

has_many :lead_bands, class_name: "Band", foreign_key: :leader_id
has_many :band_members
has_many :bands, through: :band_members
has_many :gigs, through: :bands

validates :name, presence: true 
validates :email, presence: true 
validates :email, uniqueness: true
end

class Band < ApplicationRecord

belongs_to :leader, class_name: "User", foreign_key: :leader_id
has_many :band_members
has_many :users, through: :band_members
has_many :gigs

validates :name, presence: true

def empty_roster
    self.band_members.each do |band_member|
        band_member.delete
    end
end

def unclaim_all_gigs
    self.gigs.each do |gig|
        gig.band_id = nil
        gig.status = nil
        gig.save
    end
end

def clear_associations_before_deletion
    self.empty_roster
    self.unclaim_all_gigs
end
end

Wait, I thought you were going to talk about your invite model?

There's no invite model. Let me explain.

  create_table "band_members", force: :cascade do |t|
    t.integer "band_id"
    t.integer "user_id"
    t.datetime "created_at", precision: 6, null: false
    t.datetime "updated_at", precision: 6, null: false
    t.string "status"
  end

There's no invite model, because a band_member entry with status= "Pending" is an invite.

class UsersController < ApplicationController

...

  def invite_member
    user = User.find(params[:user_id])
    invite = BandMember.new(user_id: params[:user_id], band_id: params[:band_id], status: "pending")
    if invite.save
      redirect_to user, notice: "Invite sent."
    else
      redirect_to user, notice: "Either something went wrong, or this user is already in that band. Please try again later."
    end
  end

  def invites
  end

  def accept_invite
    invite = BandMember.find(params[:id])
    invite.status = "Accepted"
    if invite.save
      redirect_to invite.band, notice: "You've joined #{invite.band.name}."
    else
      redirect_to invites_path, notice: "An error occured, please try again later."
    end
  end

 ...

end

"Invites" are just BandMember records with status "Pending", which, when initially created, all BandMember records are (with the exception of the record that is created for the band leader, which happens when the band is created). A user has to post to the accept invite path to change the status of the record to "Accepted"

Users interact with these controller actions from the views:

views/users/show.html.erb
...
<% if current_user_is_band_leader? && current_user.id != @user.id %>
    <div class='invite-wrapper'>
        <%= form_with(url: 'bands/band_members/new', method: 'post') do |form| %>
            <%= form.hidden_field :user_id, value: @user.id %>
            <%= form.label "Invite to:" %> 
            <br>
            <%= form.collection_select(:band_id, current_user.lead_bands, :id, :name) %>
            <br>
            <%= form.submit "Invite", class: 'button' %>
        <% end %>
    </div>
<% end %>
...

When viewing a musicians show page, if the viewing user is a band leader, they get a form that's just a drop-down with the bands they lead and a button that says "Invite".

The user then has an "invite" so when they view the invites path, they see this:

If they accept, the form is submitted to the accept invite path, and the entry for the associated BandMember record is updated, and those updates are persisted.

The user is redirected to the page for the band that they've joined, and a button to leave the band is now present, so that they have the ability to un-join, as it where.

And that is, more or less, the life-cycle of an invite in this model. A user can't decline an invite, they can only let it sit unaccepted, because frankly figuring out how to build a protection against invite-again-on-rejection-abuse seemed like a big hassle to include in the MVP.

Iterating to create dynamic web elements.

JesseNReynolds — Sun, 22 Nov 2020 23:06:31 +0000

I have a confession to make: I hate writing these blog posts. It's not as though I'm going to have some greate contribution to make to the understanding of software development at this point. I've been doing it all of two months, and although I think I'm doing well, I'm certainly no expert. Nothing I do here is going to be truly novel or innovative; clever, maybe, at best.

So anyway, let me walk you through some of the hopefully clever workflows I developed in this project.

By using the attributes of ruby objects that mimic database rows and iterating over collections of those objects, we can dynamically create elements on our webpage that contain the data of our database in visually pleasing ways. If we want to display all books, for example this:

(please forgive the improper class name formatting)
and this:

becomes this:

The thing I'm most proud of achieving in this view is probably that each of those book card elements is actually an a-tag that's modified to be a flex-box object, meaning I have modern feeling "clicky-divs" without using any javascript, and because each of these cards is generated from database data, what cards you'll get is determined by what books are represented on the database. If a user adds a book, it just shows up, and if a user removes a book, it just won't be there next time you load the page.

It's not an earth-shattering idea, I'm sure someone else has done this before. But hey, I think it's clever, and there's a lot of places on this app that I got to create a solution to a problem like "how should I display all the books?" and when I had the solution working and styled I thought to myself "hey, that looks good, and the way it happens is pretty clever".

I guess what I'm saying is that when talking about the adventure of learning to code, maybe the real treasure is all the "heh, I'm clever" moments we had along the way.

My first project

JesseNReynolds — Sat, 24 Oct 2020 00:37:01 +0000

When I signed up for Flatiron School, I started keeping a little idea log for apps to build. I opened that idea log up when it was time to plan my first project, and I grabbed one I thought would be fun and could be factored well into the project requirements. What I found surprising was how quickly my minimum viable product came together! Sure, it didn't check off all the boxes I wanted to, but it did what the app wants to do at it's heart.

From there it was a matter of adding features, refactoring things that are not best practices, improving the interface, streamlining the logic, etc.

What seemed a few weeks ago like it would be a big job seems easy now, at least in recollection. Of course there were moments of frustration; there were things that made me confused, things that I just could not get working for the longest time, but every time I checked something off my features wish-list, I got a nice hit of dopamine that made the whole process very enjoyable.

It's not perfect, it's not finished but it works, and I built it.

I learned some stuff, like using a while loop to control for answers to prompts that aren't understandable or would create problems down the line, instead of using recursion.

def filter_price
        complete = false

        while complete == false
            puts "Do you want to filter by price? (y/n)"
            answer = gets.chomp
            if answer.downcase == "y" || answer.downcase == "yes"
                puts "Restaurants are given price ranges from 1 to 4, where 4 is the highest."

                puts "Please enter a minimum price range from 1 to 4 (decimals NOT OK!)"
                min_price = gets.chomp.to_i

                puts "Please enter a maximum price range from 1 to 4(decimals NOT OK!)"
                max_price = gets.chomp.to_i

                complete = true

                if min_price > max_price 
                    puts "Please enter a maximum price range that is higher than or equal to your minimum price range."
                    complete = false
                end

            elsif answer.downcase == "n" || answer.downcase == "no"
                min_price = 1
                max_price = 4
                complete = true
            else
                puts "Sorry, I don't understand, please respond with y or n"
            end
        end

I got more practice writing methods from scratch, passing data around, creating objects with that data, and iterating over the objects to actually do stuff with the data inside.

The jump from the JSON data that Yelp returned to properly instantiated data attached to objects created a fun challenge that I was able to solve with meta-programming to help improve scalability and compatibility in the future.


    def self.new_from_json(parsed_data)
        parsed_data["businesses"].each do |business|
            new_restaurant = Restaurants.new

            business.each do |key, value|
                new_restaurant.class.send(:attr_accessor, "#{key}")
                # creates attr_accessor for each key in the imported hash  
                new_restaurant.send("#{key}=", value)
            end

            new_restaurant.save
        end
    end

Overall, I think my favorite part of having the chance to do something like this, to build something that I wanted, see the finished product work, and even using it here and there in my daily life, is a familiar feeling in an odd way. I've long been an advocate in my personal life for productive hobbies like leatherworking, woodworking, sewing, or knitting. I think so often we live lives of abstract productivity, rarely seeing a product or process through from start to finish, and there's great empowerment in the manifestation of something from material and desire. The fact that that feeling of empowerment and achievement is present in developing code makes me feel more certain that I've made a choice in changing careers that will bring great satisfaction to my life; and I think that's really pretty cool.