DEV Community: Ryan Pierce

Diving into Promises

Ryan Pierce — Thu, 05 Jan 2023 02:59:10 +0000

Introduction

While working on my most recent project I ran into an issue that stumped me. It had to do with these snippets of code.

Part I - Understanding the Error and Getting More Familiar with Debugging tools

This function and this ternary expression were giving me a real headache. When the component loaded and these 2 snippets of code ran, they would both throw the same error at me. The error essentially told me that ‘recipe.user.id’ and ‘recipe.steps’ were null. The first thing I did was ‘console.log(recipe.steps)’ in order to see if it was really null. The console log spit out a valid Json object with the nested steps data I was trying to access. This honestly only added to my confusion. I was sitting there with my 2 project partners, racking my brain about what could be wrong.

I decided to console log my ‘recipe.user.id’ as well, and the same thing happened; I got valid Json data back. So why then was this code breaking, why was it saying everything was null if my console logs were showing something different?

Eventually, after a recommendation, I decided to use the tool, ‘debugger.’ Debugger freezes the code in place and lets you check out specific variables in the console.

After adding the debugger and freezing my code in place, I decided to check ‘recipe.steps', and who would have guessed it (I’m sure plenty of people, but humor me), ‘recipe.steps’ was returning null. Not only that, even just ‘recipe’ was returning null. Now I was confused, why was ‘recipe’ null in the debugger but not in my console log?

The reason is because ‘console.logs’ behavior is inherently different from something like a ‘.map’ or a ternary expression. Rather than being able to log null like a ‘console.log’ can, ‘.map’ and ternary expressions can’t just work off of null; if something is null, they break and throw errors. The console log was running every time the state changed, so once the recipe really did show up, the component would run again, and my console log would show me what I wanted. My issue was that these functions and expressions were running before my recipe data fully showed up and would break rather than just running until it worked.

Part II - Finding a Fix and Diving into Promises and Async/Await

So, now I knew what my issue was, but I wasn’t totally sure how to resolve it. Do I just use a sort of time out, do I need to render null on the page until ‘recipe’ is loaded? As a newer developer, I was having a hard time thinking of a way to navigate this issue, and that's when I remembered promises and asynchronous code.

I didn’t exactly know how, but I thought that this avenue may be able to resolve my issue, so I decided to dive in. I read through a lot of documentation and watched a lot of youtube videos to get more familiar with ‘Promises.’ I learned that a ‘Promise’ is an object that represents what you want, it is a placeholder for a value that you may not have yet. In this case, this promise was a placeholder for the ‘recipe’ that was taking a little bit of time to get there. It could essentially tell my code, “hey I know that ‘recipe’ isn’t here yet, but I promise it will be, just take my word for it.” It felt like I was moving in the right direction, I just needed to implement it.

Part III - Implementation to Code

While researching ‘Promises’ I also came across the keywords ‘async’ and ‘await.’ The documentation and videos on these keywords showed me that they were exactly what I needed in order to get this ‘Promise’ working. ‘Async’ and ‘await’ allow us to write code that looks synchronous, while actually being asynchronous. To use async/await, you first need to define a function as async. This tells JavaScript that the function contains async code, and that it will return a Promise. Then, you can use the await keyword inside the function to wait for a Promise to resolve before moving on to the next line of code. Here is how I applied it to my code:

While the data is being fetched, the component will render a "Loading..." message by checking if ‘recipe’ has arrived. Once the data has been fetched and stored in the component's state, the promise will be fulfilled, ‘recipe’ will no longer be null, and the component will render the data instead of a loading div.

Part IV - Conclusion

In the end, even though bugs can make you want to pull your hair, this debugging led me on an awesome journey that has made me a better developer. Through trial and error, we can better ourselves and learn something new. So next time you get a bug, don’t pull your hair out, think of it as a learning opportunity, and once all else fails, then you can start pulling.

Ruby and OOP

Ryan Pierce — Mon, 28 Nov 2022 21:38:02 +0000

3 weeks ago, I started learning the programming language Ruby, as well as started to get comfortable with Object-oriented programming. The first week was a bit of an adjustment for me because I didn't know what to expect from Ruby. For the first couple phases, as well as my prep course, we learned JavaScript, so learning Ruby, SQL, Active Record, and plenty of other concepts was fairly difficult. One thing that helped me though, was really focusing on Object-oriented programming, and linking my learning to the concepts of these objects and classes.

Object-oriented programming (OOP) is a programming paradigm that uses objects and their interactions to design and program applications. It is one of the most popular programming paradigms and is used in many languages, including Ruby. OOP has several benefits over other programming paradigms, such as improved code reusability and readability.

There are many benefits to using object oriented programming, or OOP. OOP allows for code reuse, which means that once you have written a piece of code, you can use it again in other programs. OOP also makes it easy to create modular code, which is code that is organized into small, self-contained units. This makes it easy to debug and test code, because each module can be tested separately. Finally, OOP can make code more readable and easier to understand.

Ruby is an object-oriented programming language that allows programmers to create and use objects in their code. Objects are created from classes, which are blueprint definitions that describe the object's characteristics and behavior. Once an object is created, it can be used in code just like any other data type. Ruby's object-oriented features make it easy to create and use complex data structures.

When working with Ruby and Object Oriented Programming, it is important to set up your class in a way that is logical and easy to understand. In most cases, you will want to start by defining your class and its methods in a separate file, and then require that file in your Ruby program. You can also use the Ruby Object class to create a new class, but this is not always necessary. Once you have your class setup, you can start adding objects to it by using the new method.

When working with these classes, there were a few ways that I like to keep everything straight in my head. I liked to make a map with all of my databases, all of their relationships, and all of the functions I would be able to access within these relationships. It is similar to writing an essay outline so that I have a clear framework to work off of.

Well that's the gist of what I learned about Ruby and what OOP are! By sticking to the concepts and logic, I was able to work better through this difficult phase. Thanks for reading!

React Component Hierarchy

Ryan Pierce — Fri, 04 Nov 2022 18:08:29 +0000

In react, Components are the basic architecture by which we create our web application. They are independent and reusable bits of code that we usually have return JSX (JavaScript XML) to other Components which are then rendered onto the page. Components follow a hierarchy with App usually being our topmost layer and all other Components being children and grandchildren of it.

Here is a basic example of parent and children Components.

App is our parent and we are having it return its child Component which we have named “Child”. Where hierarchy comes into play, is that we can pass information from our parents to our children through props. I have named some basic props that we are passing down named “prop” and “setProp” which are state related variables.

We then access the props information by destructuring them using the “{ prop, setProp }” syntax. I had this component make a simple button that will flip our prop state from true to false and vice versa whenever it is clicked. Setting the state in a way like this allows us to pass information from a child Component to a parent. You can imagine that in a complex application we might have many more Components with more and more hierarchy complexity as well. Hierarchy is important because it allows us to keep our code easy to follow and maintain.

This is a slightly more complex structure, and to show the importance of understanding your hierarchy, let's say you need to change state in “Grandchild” and you need to access that new state in “Grandchild2,” how might we go about doing this? Where should we put our state variables?

Well, we could create the state variables in our App Component and then pass those down as props to each Child, and then have those children pass those down as props even further to each Grandchild. This encapsulates an important practice in react which is to give state to the most recent common ancestor of each Component that needs it. In this case, that ancestor is App.

Recently, I was participating in a project and I was having a rough time with a particular state variable. The variable had to do with a randomizer function I created that would return a random object of images from an array. Each of these objects contained a home with a closed door, an open door, and a house that had been “toilet papered” (tpd).

(array of objects containing house images)

My goal with this was to assign one of these objects to a state variable that would iterate through an open door porch, to a closed door porch(after an action has been performed), and sometimes a “toilet papered” porch (after a different action). The issue I ran into, is that every time state is changed by setting it, a Component is re-rendered. This meant that every time I would try and set my porch's state to a different image, my randomizer function would run again, thereby selecting a new random porch rather than keeping my porches consistent. I needed to figure out a way to set my porch, and then just iterate through it without rerunning my randomizer function. With so many different states and Components working together in this project, it was a difficult task to find out where everything needed to go in my overall hierarchy. This is the approach I ended up taking, and hopefully you can learn a little more about hierarchy and how we can play with the props we pass down to get the results we want.

The first thing I did was create the state variables in the topmost Component, App.

Then I passed those variables down to the children that needed access to them.

In this case, the Component SpookyStreet only needed access to setting it, and HousePorch only needed access to the current state.

I then put the randomizer into SpookyStreet, where it set the currentPorch state to that random object (which is passed up to App and then passed down to HousePorch), and then navigates to the HousePorch component which is a sibling of SpookyStreet.

(randomizer)

(setting state and navigation)

Finally, the HousePorch component has access to that state we set in its sibling, and can iterate through that object's 3 different image types.

In conclusion, I hope I helped illustrate the importance of Component Hierarchy in React, and some of the ways we can use it in application development. As our applications increase in complexity, so too will our hierarchy, and keeping it clean, readable, and easy to follow are extremely important as we build them out.

Assigning a Variable May Not Always Be As It Seems

Ryan Pierce — Wed, 05 Oct 2022 15:18:55 +0000

So recently while writing some code, I ran into an interesting problem that kind of boggled my mind. Pictured below is the code snippet that I will be discussing today.

function handleSubmit(e) {
    e.preventDefault();
    let totalVotes = document.querySelector('#vote-count').textContent

    parseTot = parseInt(totalVotes)
    parseTarg = parseInt(e.target.votes.value)
    totalVotes = parseTot + parseTarg

    document.querySelector('#vote-count').textContent = totalVotes

    currentCharacter.votes = totalVotes

    patchCurrentCharacter(currentCharacter)
}

The section of code I would like to discuss is the first 6 lines of my function “handleSubmit”. On the second line, I create a variable called totalVotes in which I then assign the value of document.querySelector(‘#vote-count’).textContent. So why, then, do I have to restate that exact thing on the sixth line? Why doesn’t the 5th line cover what needs to be stated on line 6, and even then, why couldn’t line 6 run as totalVotes = totalVotes?

This is where the title of my post comes in. On my second line, all I am doing is assigning my totalVotes variable the literal text content at that location, which could be anything. If I console.log(totalVotes) here, I get whatever that text content is, I don’t get back “document.querySelector(‘#vote-count’).textContent. This means that I can't alter that html elements text content with my totalVotes variable, because it isn't linked to that element necessarily, it is only assigned that elements text content.

As someone new to programming, this was difficult to catch in code, and was almost just as difficult to understand while someone explained it to me. However, I feel like this particular case is something that requires a sort of Eureka moment: a moment where you don’t understand initially, but once you do, it makes total sense.

Hopefully I was able to help you towards your Eureka moment if you are also struggling with this concept!