DEV Community: John Roy

Troubleshooting for the easily panicked.

John Roy — Fri, 28 Oct 2022 15:31:28 +0000

Fetch! Not Just for Dogs Anymore!

John Roy — Tue, 11 Oct 2022 17:24:41 +0000

In Phase 3 and Phase 4 of the Flatiron School’s Software Engineering bootcamp, the focus is on creating backend API’s and coherent databases. In Phase 4, integrating the backend and frontend was a main focus of Project Week. While moving data from the frontend to the backend and vice versa is only one step, it is a crucial “make or break” component of your app. Without this data exchange, the front and back of your app are two separate entities, leaving both components purposeless. This “last-mile delivery” of data may be the most important part of your app.

In JavaScript and React, a “fetch” is used to send data back and forth from the frontend and backend. There are different types of fetch that we use depending on what we want to do with the data. A "GET" will retrieve data from the API, a "POST" will send a new piece of data from the frontend, "PATCH" and "PUT" will modify data on the backend using data from the frontend, and a "DELETE" will remove data specified on the frontend from the backend.

The method by which we will get the data from the API to the frontend is called a “GET” request. You do not need to specify in the fetch request if it is a “GET”. For example:

fetch('https://fakesite.com/api')
  .then(response => response.json())
  .then(resp => console.log(resp);

In this fetch request, we are telling the fetch where to look with a URL in the first line. The fact that we are performing a "GET" is implied as we have not specified what fetch we are doing. The second line is telling the fetch that we are expecting the response data in JSON format. This can be JSON, text, specific form data or other formats depending on what you are doing. The third line console.logs the response. You can also assign this to a variable and use the data elsewhere in your application.

Performing a "POST", "PATCH", and "PUT" require more information than a "GET", but are quite similar to each other. In fact, the syntax is the same for all, it's just the data and what's done with it on the backend that are different. Here's an example:

            fetch("https://fakesite.com/api", {
            method: "POST",
            headers: {"Content-Type" : "application/json"},
            body: JSON.stringify({_this will be the data object you are sending_})
        })
            .then(resp => resp.json())
            .then(data => console.log(data))

You can see on the second line that we have had to specify what fetch method we are wanting to use. The third line tells the API that we are sending JSON data. Again, this may vary depending on your requirements. The fourth line converts your data to JSON format. This will send your object to the API and create a new item in the array. "PATCH" and "PUT" function similarly, but you have to specify which object in the array you are addressing. Also, with a "PUT" you have to enter every value for an object. For a "PATCH" you only have to enter data you wish to modify.

To delete and object from an array is much simpler than the other fetch methods. A typical "DELETE" request looks like this:

   fetch('https://fakesite.com/api', {
        method: 'DELETE',
      })

You will have to have an object specified to make the "DELETE" work. There are multiple ways to do this, but we are not going to touch that in this blog post! You can also return confirmation messages or other things if you wish to after the object is deleted.

This blog post is definitely not earth-shattering. As usual, I took a subject that I didn't feel fully comfortable with and studied it so I could explain it, and this helps my comprehension!a

A good name is to be chosen rather than great riches...

John Roy — Fri, 16 Sep 2022 17:14:02 +0000

Ruby is a high-level programming language that was created in the 1990’s. It is an object-oriented language and is frequently used in backend development. I am a student at Flatiron school, and our introduction to the backend was made using Ruby. One of the challenges my group ran into while doing our phase project was how to name our different objects. A situation came up where I realized that naming conventions should not just apply to those working on the project, but they must make sense to people outside of that project. Names should also be “readable”. Your naming convention should use real words and phrases as much as possible.
Most important, in my opinion, is that your names be descriptive. Your names should tell the reader what an object is, and where it fits into the hierarchy. A series of variables named “c1, c2, c3”, etc are obviously related. It’s good that you can tell that these variables are related, but that doesn’t tell us anything else about them. Are they also related to the variables named “b*”? You can’t really tell from the name. If c1 refers to the name of a city, then the variable could be called city, or cityName. If c1 is an array that incorporates data about a city, perhaps cityData would be good. Or if there are multiple data sets, maybe cityDemographics, cityGovernment and cityMeteorology would be more appropriate. It is also entirely possible that “city” is too generic, and cityDemographics should actually be anytownDemographics to differentiate it from other cities.
While descriptiveness is crucial, there are several smaller concepts that can also make or break your naming convention. While descriptiveness is the most important thing, it is not the only thing. If you require an entire line of code to describe a variable, you may need to revisit how your code is organized and rethink the names! A name should be just long enough to be descriptive enough. Consistency is also an important concept in naming. The way you name objects should be similar throughout your project. A reviewer jumping around in your code should not see a jarring difference from component to component. Your naming convention should stay professional. We are all guilty of using nicknames and funny words for objects, but code should be written with a view to being reviewed by managers with no sense of humor. Also, production code with unprofessional references to the project will not endear the customer to the development team.
There is too much content on naming conventions to cover in a blog post. This is a simple post meant to cover a few basics, and give a beginner and idea of what good names would entail and pitfalls to avoid. Starting now using a descriptive and professional naming convention will benefit you later in your career. Even if you work by yourself, using a good naming convention can help if you need to bring in help. In short, everybody needs to use good names!

State of Denial, a Journey

John Roy — Fri, 26 Aug 2022 03:19:11 +0000

As a Flatiron School student, I just spent a few weeks
studying React as part of Phase 2 of the Software Engineering
program. React builds on JavaScript and is all-around a pretty powerful tool. There are still some quirky syntax requirements, but after being thrown into the deep end while learning JavaScript, it wasn’t too bad. We learned about props and components and that went well enough, but when the conversation turned to state and events, I had a pretty hard time parsing the idea of state in my head.

Dictionaries define state basically as what condition
something is in. This does work out and is pretty easy to
understand in some cases. If you have a situation where you’re working with a toggle or something similar, a Boolean value works fine. Then, state actually refers to a condition, true or false. There are situations where you have strings and arrays assigned to a piece of state and I had a very hard time understanding how those things had a “condition”. I resigned myself to working without really understanding state and that led to a decision to move forward without really getting what was in front of me already.

Moving forward at that point was kind of a bad idea. I got
into a situation where I was coding without understanding why I was doing things. I was simply pattern matching and rewriting code without an appreciation of how it worked. This led to a lot of frustration that could have been avoided had I just stuck it out and wrapped my head around what is actually going on with state. My first step was losing this need to have state as used in React match my idea of what book-definition state was.

Assigning a variable to state just allows React to hold on
to the values of these variables and change them, usually with event handling and will re-render the component when the state is changed. This is why it’s important not to implicitly re-value a variable assigned to state. Doing so will not allow React to keep up with the state and it won’t re-render the page. I was getting lost in the weeds trying to figuring out how adding a new object to an array was fundamentally changing the “state” of the variable. It wasn’t - I was just being kind of inflexible and not using the term “state” in a way that I hadn’t come across before. Once I understood what state was and what it was doing, I was able
to get over the fact that it was labeled a word I found misleading at first.

As I did a lot of reading and panicky searches of “what is
react state”, I came across the origin of the term. It is
referring to Finite-State Machines. State machines are not literal machines, but are abstractions with have a number of states which are changed in response to inputs. I wish I had gone down the rabbit hole a lot earlier, as understanding that concept helped me understand state in React. Also, one thing this process has taught me is to walk before you run!

Logging Like You're a Lumberjack

John Roy — Fri, 05 Aug 2022 03:04:00 +0000

I am currently a student at Flatiron School. I am studying Software Engineering. This is my first experience with actual coding aside from some BASIC-language programs in the heady days of Atari 800’s and Commodore 64’s. Coding in JavaScript has been quite the shock to a mind which hasn’t had to think like this in a LOT of years! While it has been very challenging, and quite frustrating at times, there has been one thing that has been to me like a lifesaver thrown to a drowning man - the console.log().

In our prework phase of our bootcamp, console.logging is a part of the curriculum. It’s one of the first things they teach you. They mention that it’s not really part of the actual program, but that it’s more of a programming tool that you’ll use a lot down the road. It really doesn’t seem like that big of a deal. It was not until we started writing functions and manipulating the DOM that I began to appreciate just how much console.logging can do for a programmer. There have been several times when console.logging was the difference between success and failure.

Console.logging is a good way to check your work along the way. Brooke, our primary instructor, harped on us early about console.logging. I didn’t really take it to heart initially. In various one-on-one sessions, instructors would constantly be telling me “Console log it. You just changed something”. If you just picked an HTML element from the DOM, console.log() it and make sure you picked the right one. You just assigned a variable? Console.log() it and make sure that you assigned it correctly. You just did a fetch request? What does the return look like in a console.log()? Knowing that you’ve done things right is really important in every phase of putting together a program.

Console.logging is also great for letting you know what you haven’t done right. No return data from your fetch? Better recheck that resource or check where you actually sent that return. You console.logged in a function and nothing happened? Did you send the right argument? Did you actually invoke the function? And don’t even get me started about console.logging variables. I’ve been coding for real for 3 weeks and I could probably write a book about all the different ways you can jack up assigning or operating with variables!

If it sounds like I love console.log() then I have really understated this post! I try to LIVE it. Every time I write out a bunch of stuff, it inevitably doesn’t work. Then, I have to go back in and try to figure out what’s going on and there’s a LOT to root through. If I had just console.logged as I went, I would at least know what DOES work and if you know that all of your fetch data, DOM elements and variables are right, then you’ve just narrowed things down a lot. Maybe I am a little TOO into console.logging. I console.log() nearly every time I fetch, assign variables, operate on variables, or pick elements from the DOM. It is not the end-all be-all solution, but it certainly has helped me, and made troubleshooting more manageable.