DEV Community: Joseph Knopke

Props vs. State in React

Joseph Knopke — Thu, 07 Oct 2021 16:50:00 +0000

One question that came up when working with React was: What's the difference between props and state? But before we explore their difference, let's look at their similarities: Props and state are both plain javascript objects, and they both hold information that affects the render output in a component.

The key difference between the two is that props is passed down from the parent component to its children, whereas state is created and managed within the component. Props is therefore immutable, and should not be changed, only passed down. State, on the other hand, is changeable, internal to the component, and is therefore not passed down to children components.

Props

Since props cannot change during a component's lifecycle, they should be used when handling information that does not need to be acted on or edited. These components are known as "pure" or "stateless" components.

State

State should therefore be used to handle changes internal to a component. When a stateful component first mounts, it is given an initial or default state. Based on user interactions, this default state will change and be re-rendered.

`setState()`

Using the setState() method, state can be mutated. It is important to note that setState() is asynchronous, and should therefore be passed a function instead of an object. This will ensure that setState() is always passed the most recent version of state.

Here is an example from the reactjs official documentation:

The below function will not work as intended, because setState() is being passed an object.

incrementCount() {
  this.setState({count: this.state.count + 1});
}

Instead, the above should be written like this:

incrementCount() {
  this.setState((state) => {
    return {count: state.count + 1}
  });
}

Because a function is being passed, the incrementCount() updater will act on the current state, and be able to chain its updates. Before, with this.state the updates would act upon the default state value each time, which is not the desired action.

Summary

To review, Props are immutable values that are passed down from parent components to their children. Props cannot be changed during a component's lifecycle.

State is handled within a component and is "private" to that component. It starts with a default value that changes over time based on user interactions.

Reducers: Confusing Yet Convenient

Joseph Knopke — Mon, 27 Sep 2021 12:22:21 +0000

When I was first introduced to Redux, Reducers were extremely difficult to wrap my head around. They seemed like an unnecessary source of headaches and confusion. I quickly learned how wrong I was.

See, Reducers are actually beautifully simple. At its core, a Reducer is a function that accepts the current state and an action as arguments, and returns a new state in result.

(state, action) => newState

An important note here is that Reducers must not mutate the initial or current state - they always produce a new state following an action.

A Reducer can therefore be the perfect way to help with any CRUD functionality you might need. Simply call one of the cases defined in your Reducer through a function defined in an actions file

Self and This

Joseph Knopke — Thu, 26 Aug 2021 12:53:40 +0000

The self keyword in ruby is used to access the current object, depending on the context in which it is used. For example, when used in an instance method, self refers to an instance of the class. When used in a class, self refers to the Object of whichever class it's used in. This allows for code that's easier to read and change, and also useful for debugging purposes.

The this keyword in javascript has some similarities to self in ruby, but also some key differences.

The value of this depends heavily on the context in which it is called, and also whether it is called in strict-mode or non-strict-mode. In the global context, this will refer to the global object, which is often the window object. In the context of a function, the value of this will depend on how the function is called. If the value of this is not set by the call, it will automatically default to the global object.

In the context of a Class, this is a regular object, similar to self in ruby. This can be used in the constructor function of a class, and becomes self-referential.

When the bind() method is used, this will become bound to the first argument of bind, regardless of the context in which it is used.

This seems like a more confusing keyword than self in ruby, but it is also extremely useful and important when using Javascript.

HTML Form Elements

Joseph Knopke — Thu, 04 Mar 2021 08:29:40 +0000

When creating a HTML form, the tag can be a jack of all trades. <input type="text"> prompts a user with a small text box. <input type="button"> prompts the user with a clickable button. There are a bunch of other input types including "email","username","password","checkbox", and of course "submit".

All of these input types cover alot of bases, but there are a couple of other HTML form elements that can be useful too. Here's some others that I used when making my first Sinatra app, which lets users make their own custom spells for D&D.

The `<textarea>` Element

The <textarea> tag creates a larger input field for when you want to give the user more room to respond. In my spellmaker app, I wanted the user to have more room for the spell description, so I did the following:

<label for="desc">Description:</label>

<textarea name="desc" rows="5" cols="50">Type Description here...</textarea>

The size of the textarea can be adjusted with the rows and cols attributes, and if you'd like to have some sort of message or default text in the box, just place it in between the start and end tags!

The `<select>` Element

The <select> tag creates a drop down list. Perfect for presenting the user with a selection of options, like Schools of magic:

<label for="school">School:</label>
    <select name="school">
        <option value="Abjuration">Abjuration</option>
        <option value="Conjuration">Conjuration</option>
        <option value="Divination">Divination</option>
        <option value="Enchantment">Enchantment</option>
        <option value="Evocation">Evocation</option>
        <option value="Illusion">Illusion</option>
        <option value="Necromancy">Necromancy</option>
    </select>

Now the user can select from a curated list of options. You'll notice we simply use the <option> tag to make each option.

The <fieldset> Element
This tag is a way of breaking up a form into two separate boxes. I didn't actually use this one for my project, but here's an example nonetheless:

<form>
  <fieldset>
    <legend>Person:</legend>
    <label for="fname">First name:</label>
    <input type="text" id="fname" name="fname"><br><br>
    <label for="lname">Last name:</label>
    <input type="text" id="lname" name="lname"><br><br>
  </fieldset>
  <fieldset>
    <legend>Pet:</legend>
    <label for="pname">Name:</label>
    <input type="text" id="pname" name="pname"><br><br>
  </fieldset>
  <input type="submit" value="Submit">
</form>

This is a stylistic element that draws a box around different parts of your form. The <legend> tag can be used to caption each box.

Building a CLI Spell Finder for D&D 5e

Joseph Knopke — Sun, 10 Jan 2021 22:15:11 +0000

It took me longer than I'd like to admit to come up with an idea for this CLI project to end Phase 1. I spent several days trying to wrap my head around using APIs and scraping, but I still found myself ridiculously confused on even just the basics of navigating an API.

After watching and rewatching a dozen different videos and lectures on APIs, I thought I was finally ready to start working on my own project. The public API that immediately caught my eye was a database for D&D 5e. While i'm not the most knowledgable or experience D&D player, it is a game that I thoroughly enjoy playing. On top of that, this API is incredibly readable and user-friendly, as it allows access to a vast amount of information through a variety of endpoints.

When beginning my project, I decided to narrow my focus on spells, as it was a large enough pool of data to play around with, but not so large where I could get lost on my first ruby CLI project.

My first idea was allowing the user to search for a spell by name, then returning a bunch of relevant data about the spell they searched for. I knew I would need a class that created different Spell objects, as well as a class to get those objects from the API.

Implementing this functionality was simple enough: I just need to get user input, use the downcase and gsub methods to add the correct formatting, and then plug the result into the url.

(I know I said it was "simple enough," but you won't believe how excited I was when I finally was able to return a hash I could use and pull data from)

The resulting hash contained a bunch of information about the inputted spell, but I noticed something strange about the formatting pretty quickly. Some of the keys had array values, while some had string values. I know this is exceedingly common, but when I first tried pulling info from my hash it definitely tripped me up.

With enough prying around, I was able to return the values I wanted, but just when I thought I was good to go- AN ERROR!!!

undefined method `[]' for nil:NilClass

After scratching my head for a while, I realized that one of the attributes I was pulling from the spell's hash must've had an empty value. See, I was searching through the hash and defining instance variables like so:

@damage = spell_data["damage"]["damage_at_slot_level"]

But what if my spell doesn't have any damage?? An empty value would still be assigned to @damage, and trying to call the damage getter method results in our error.

So, I needed to change my code so that spells without damage would simply return Damage:N/A, rather than breaking my code.

I come up with the block below:

if spell_data["damage"] && spell_data["damage"]["damage_at_slot_level"]
            @damage = spell_data["damage"]["damage_at_slot_level"]
        else
            @damage = "N/A"
        end

I paired this with the code below, in order to actually return a value in my CLI class:

if @spell.damage != "N/A"
      @spell.damage.each do |lvl, dmg|
           puts "Level #{lvl}: #{dmg} damage"
      end
   else
      puts "N/A"
   end

By implementing this code, I made sure my program wouldn't break when presented with a spell that didn't have a damage value.

While it may be a simple solution upon reflection, overcoming this error felt like a big success at the time! I added some more functionality to the program: allowing users to search for a list of spells by level or by school of magic. Also, after the search results were presented, I allowed for users to either search again or exit the application.

I know this is a super basic project, but it was definitely exciting to see the potential of a CLI. Building out the app on my own was definitely a rewarding process (albeit frustrating at times).

I'm already thinking about the ways I could expand the current application!

Two weeks in...

Joseph Knopke — Sun, 20 Dec 2020 23:16:08 +0000

My first exposure to computer programming was 8 years ago, when I took Visual Basic in highschool. While Visual Basic is virtually extinct now, it was still a good introduction to the world of code, to the capabilities, theories, and purposes of computer programming. Eight years later, with all of that Visual Basic knowledge long gone, I find myself learning the basics of a computer programming language yet again.

Over the past couple weeks, while working through labs and attending study groups, I have also been asking myself - Why? Why am I completely changing my career path, doing something that doesn't really relate to my bachelor's degree or previous lines of work?

The first thing that attracted me to flatiron's software engineering program was simply the usefulness and practicality of a software engineering degree. Obviously coding is a widely applicable skillset, something that can be used in a variety of different fields and markets.

Another thing that initially attracted me to programming was just the process of creation that takes place. Throughout my academic experience, I was constantly involved in the creation of things: essays, stories, poems, plays, musicals, drawings. While these things are vastly different from computer programs and software, the process of creation is still similar.

I'm happy to say that, two weeks in, I still feel good about my decision to enroll in the software engineering program at flatiron. There have definitely been ups and downs, but all in all I have been thoroughly interested in the content, and I have enjoyed the learning process.

The most exciting moments have come when talking and working with classmates over zoom: I have received a lot of help and guidance from the people in my cohort, and I know that they will continue to be an important resource for the rest of the course.