DEV Community: Penelope Durand

A Workaround - "Uncaught TypeError: Cannot read properties of null"

Penelope Durand — Fri, 15 Jul 2022 20:01:39 +0000

Introduction

While working on a project I encountered the dreaded issue below:

There are so many different errors that one is constantly debugging, but this error threw me in for a trip due to the fact that even if I changed the initial state for where this error was coming from -- it still persisted. Tough little bug, good thing I'm about to introduce a funky workaround!

Context for Error

To give some context, in the project I incorporated a map from Mapbox to tag different locations on the map through coordinates. In this project I called them the "markers". I also used the "Popup" feature in the map so that the user could click on the selected marker and read more information about the tagged location.

When the user clicks on "See More" the page renders the individual information about the specific cat associated with the marker. Evidently, I needed to use state for the selected marker. Therefore, the latitude and longitude were initiated with a state of "null" since initially, no markers will be selected until the user clicks on one specifically.

The problem started occurring after you were finished reading the information about the associated cat with the location. If you wanted to click on another area of the map or close the popup, the error message would come back to haunt you:

Since we were looking to see more information based on the cat associated with the marker, it would give the error that it "cat" is set to null because of the function I wrote to handleClose as soon as the marker was closed.

Upon closing the popup, I wanted the state for the markers to be reset to null. The markers needed to be reset to null so that we could continue to use the map and click on other markers. However, as soon as I would reset the state to null the rest of the code for the site could not proceed. Since the route was already /cats/14 the code was trying to render the next individual cat associated with the selected marker and to display the following information:

The issues lies in that since "null" does not have a cat associated with it, the route /cats/:id cannot render correctly, and thus the site breaks and the page renders blank.

The "Workaround"

I am hesitant to introduce this workaround, because in all honesty I cannot say that it is a good solution, nor does it actually "fix" the issue. However, it made the page work in that it provided an illusion that the user's experience was not being interrupted.

First, I tried refreshing the page when the route was /cats/:id to see if it would at least refresh back to the previous state. Still, the page rendered blank and the site broke. I flipped back to another route /cats to see if that would help get the user back to a working page, and it worked. So I came to the conclusion that three major things needed to happen. First, the state for the selected marker absolutely needed to be reset to "null", because the user needed to be able to see other pages. Second, I needed to redirect the user to a working page without refreshing. Third, this all somehow needed to happen smoothly to not interrupt user experience.

The final code I came up with that would accomplish all three is below:

The code accomplished the goal of resetting the selected marker state to null on the first line. The second line shows that the code worked to redirect the user to a working page in order to avoid experiencing the site breaking. Lastly, the third line, upon redirection, immediately takes the user back to the map which is where they were initially interacting with the popup feature. Therefore, the user does not necessarily notice that they have been redirected to another page unless they were scrolled outside of the map display area.

Again, I am positive there is a cleaner and smoother solution out there, but for the time being for this side project of mind -- this worked!

On SpongeBob's birthday week there must be another analogy!

It would be out of character to not include another funky analogy related to SpongeBob, so as always, here's how I think about this workaround code.

There's an episode in the first season of SpongeBob called "Opposite Day". During this episode SpongeBob and Patrick go through the day pretending to be Squidward.

As long time viewers of the show we know the truth. Neither of them are Squidward even if SpongeBob shapes his head to look like him. However, they do a good job of convincing the real estate agent that went to check out Squidward's house. When she first meets SpongeBob she simply mentions that she thought he would be taller, but nonetheless believes him, albeit confused, when he says he is Squidward.

Think of our code as SpongeBob and our user as the real estate agent. Though the code used above works, there can still be differences spotted from a true solution. It looks and acts like a solution, just like SpongeBob looks and acts like Squidward, but it is still technically a "workaround" as opposed to a cleaner solution.

Conclusion

To the coders, who in this analogy would be the viewers, we can probably spot the differences and what can work better. However, when it comes to other users I am grateful that they may enjoy the usage of the site with limited interruption. Thankfully, this workaround is effective enough and I was given peace of mind knowing that at least the real estate agent (or user) didn't walk out on it because the site was too impractical or confusing!

The less interruption the user has, the better their experience will be, and the more likely we are to have them revisit us. Happy coding!

useParams in React Router

Penelope Durand — Mon, 27 Jun 2022 08:17:32 +0000

What is useParams?

Part of developing a web application requires you to develop different routes. However, the more information you work with on your application routing can become tedious. You have to personalize each route so that the user can attain specific information and navigate to different pages which contain even more information.

Now image if you are working with listing different 100 different types of cookies that you want to introduce to the user. You would like the user to be able to click on each cookie card and be rerouted to that specific cookie's page. How would you approach this? Would you hard code all of their routes out?

<Route exact path="/cookie1">
     <Cookie1 />
</Route>

...

<Route exact path="/cookie2">
     <Cookie2 />
</Route>

...
That's 100 different routes you'd have to do this for!!! It gets me stressed out just thinking about that...

Thankfully there is no need to do that! There is a hook that is able to save another day! useParams is a hook that is used to set up navigation with routes. By using useParams you make your routes more dynamic by passing through the route a specific parameter you want to work with (does not matter what it is called). Instead of the long and painful way above, our code would look a little more like this:

<Route exact path="/cookie/:type">
     <CookieCard />
</Route>

An Example:

Building off of our issue above, we are going to work with three different components. The first component will be App where we will be writing the route for the CookieCard component and passing down the "cookies" data we have.

Once we have set up our route we move into building the CookieCard component. We have passed down the cookies data as a prop, we are now working to map through the data to display everything. When mapping we will include the link to our dynamic cookie route. We use string interpolation for the Link because we will be navigating to another URL for each specific type of cookie.

Now that we have written our dynamic link, it is officially time for useParams. We will be filtering the cookies information to display the specific cookie information according to the URL. Once we have filtered through the cookies we will map out the cookie so that we can display the information such as name and type of cookie. Remember, that our parameter in useParams must match our route /cookie/:type to follow proper naming conventions.

Now, we have our dynamic routes that will display the information for each cookie without having to physically type the code for each cookie!

Why is this hook useful?

Besides the fact that it makes our code simpler, it also gives the user the opportunity to focus on exploring the details of each specific cookie one at a time. By creating dynamic routing for your cookies (or whatever you are working with) it communicates that it is important enough to have its own URL/section to explore. You can make each page more creative and expand on the details displayed!

Wouldn't be a blog post without another SpongeBob analogy...

Think of our dynamic routing as Gary's brain in the episode Dumped! In this episode, Gary abandon's SpongeBob and follows Patrick around. No one can figure out why Gary is dedicated to giving Patrick his attention, but they just know that they cannot change his mind.

So in this example, our routes exact path are Gary's brain. It is concentrating on one singular thing at a time. However, in the episode Gary was following Patrick for a specific reason. If you were a fan you might have remembered that he was following Patrick because he had a chocolate chip cookie! Maybe you noticed we were working with cookies in our example above as well!

The message here is still the same though, the parameters used could have been anything. For example, it could have looked like:

/cookie/:type

or even

/cookie/:name

It would not have mattered, but what would matter is using the correct naming conventions to appropriately use useParams. Gary is the same way.. he did not care who had the cookie he just wanted the cookie (/cookie/:nameofperson). Maybe he doesn't even have a favorite type of cookie! Patrick could have had an oatmeal cookie (/cookie/:name) and he might have still followed him around. Gary had an exact path with the first goal of getting to cookies (/cookie/:type). The fact that he went the Patrick route to get the cookie was only coincidence. Patrick simply had exactly what Gary was looking for- he had the cookie.

Conclusion

useParams presents an opportunity to truly appreciate what it means to make your code dynamic. Simplify your life by continuing to explore hooks and different features presented by React. The more exploring we all do the more dynamic our code becomes!

Finding the Way with useNavigate() in React

Penelope Durand — Fri, 03 Jun 2022 04:58:37 +0000

useNavigate() - What is it?

While building an app you are bound to have multiple pages which you will need to click between. Setting up routes and pages is easy enough, but how do we build a button that can help us change routes once clicked? React, once again, comes to save the day!

React hooks have had many changes as newer versions continue to be developed. In the previous version of React we would have used the useHistory() hook to solve our problem above, but useHistory() has officially been deprecated. With the introduction of React Router v6 we were officially introduced to useNavigate().

In order to achieve our goal, we will be using useNavigate(). useNavigate() can be used in several different ways, but our particular example below it will allow us to redirect our user to a different page.

An Example:

Since useNavigate() is a hook, we must first import it correctly at the top of our functional component.

Once we have imported it, the next step is to specify that the function navigate() is being returned by our useNavigate() hook. We must do this inside of our functional component.

This allows us to use the navigate() function as a way to pass a route as a parameter that will prompt the redirection to a new page. As you can see below, we have attached the navigate() function to a function named “handleClick” which is attached to a button in the return section. Once the button is clicked, the event will trigger the navigate function which will redirect us to the specific “worlds” page. In this particular example, the navigate() function takes in the route for “worlds” as a parameter to prompt the redirection to the "worlds" page.

Why is this hook useful?

In order to make our application as user-friendly as possible, it is important to give the user a sense of direction. The user must be able to navigate through the pages without having to continuously visit the url tab and physically typing the different routes. This is why the hook useNavigate() is important. It gives the user a sense of control by making the different routes easily accessible.

Another SpongeBob Analogy...

Continuing the SpongeBob reference from the previous blog post, there is an episode in which SpongeBob and Patrick get a hold of a game which they believe to be a map to a hidden treasure. In this episode Mr. Krabs jumps on the opportunity to use this map to find the hidden treasure. However, they quickly lose their sense of direction when Patrick (the navigator) incorrectly interprets what Mr. Krabs says. Instead of "East", Patrick hears Mr. Krabs say "Weast" and finds the closest thing on the compass to "Weast".

In this case, think of your application as a type of map with different routes. There are many different paths that you can take, but ultimately you need some sort of navigation system to adequately explore what you are searching for. Our navigate() function is our Patrick (the navigator) and what Mr. Krabs says would be the parameter (or route) that is being passed through. In this case the route which we take is determined by what you type into the parenthesis of navigate().

Theoretically, if the route is referenced correctly in the code, we should be successfully redirected to the new (correct) page. However, if written incorrectly or if we leave the strings empty without a route name, we will get nowhere. Unlike Patrick, our navigate() function will not be able to guess our destination and will only explicitly interpret what we pass as a parameter. If we type the incorrect destination route, then we might be redirected incorrectly and we will get a moment like this:

If we leave our navigate() function with empty strings we may click on the button that should prompt the redirection a hundred times, but nothing will happen. The returned hook function will not be able to redirect us anywhere. If we misspell the route our navigate() function will once again fail to take us anywhere because what we have typed simply does not exist!

Keep Sharp!

Make sure you’re always testing your code to ensure that your application is running flawlessly. As developers it is our responsibility to ensure that the routes are set up correctly, our code follows the appropriate syntax, and that we know how to appropriately use the hooks provided by React. After we have set all of that up, our useNavigate() hook takes care of the rest of it!

A Funky Analogy for useState() in React

Penelope Durand — Fri, 13 May 2022 06:04:24 +0000

useState() - What is it?

React has different hooks that you can use while coding. One of these hooks is useState(). useState() gives you the opportunity to take a variable that you would like to change and preserve the current state to manipulate it in a function.

Tips & An Example:

In order to follow along easily it is recommended that you name the state variables in a way that identifies what you are working with. useState() also needs an initial state which you set in the parenthesis. In the example below we are working with the "name" of something, specifically we are working with the text that the user would type in the “name” input field. For this reason we name the variables for useState() as “name” and “setName”. Since we also know that the user will be typing a string value we actually set the initial state as empty quotes because we know that initially the input field will be empty, but will be used to evaluate a string value.

Quick Analogy

Before we move onto the rest of the explanation, I want to use an analogy that helped me understand useState() in React. When trying to conceptualize useState() I initially felt like my brain was blowing up 🤯 .

However, the more I started working with useState() I started to embrace the chaotic feel of it being somewhat like traveling through time. I started thinking about how whenever I used useState() it felt like I was bracing myself for a ride through time. Specifically I started thinking about the Squidward in the time machine episode.

If you’re new to useState(), then I want you to think of yourself as Squidward as if you were traveling through time whenever you use useState().

...back to our example!

Maybe you’re asking yourself, how? Let’s step back into the example of “name”. In this example we have a form that will be submitted by the user once they click on the "Travel Through Time!" button. Upon submission we will be evaluating the string they have typed into the input box. Therefore, in order to register that change, we write a function that will know what to do with the change that will be occurring in the “name” input field. The function is labeled accordingly and can be referenced below. As you can see the parameter the function is taking in is an event (the submission) and upon the submission we will get the value of the input field.

Since the user is inputting the string of information that we want to set as our "name" so that it can display on our browser, we will use “setName” as a way to essentially set the (future) current state of “name”. In this case I say (future) in parenthesis because before the form is submitted the state of “name” won’t be reflecting the e.target.value– it will only become that after the submission. So now that we used the "setName" to take in e.target.value, then the next time we use “name” we will have whatever was input into “e.target.value”. For example, if we console.log(name) after typing "bob" in the name input field and we click submit, we can see below that the variable "name" now is set to "bob" because that is what was our "e.target.value".

Another way to make sure our setter function is operating correctly and updating the state of "name" is by tracking the state as you are typing. In the image below, you can see that as the user types in the name input field the state is updating to whatever is in the name input field.

What happens if don't use the setter function?

It’s important to remember that you can only use the setter function to actually make the changes you want to the current state. So for example, if we typed name(e.target.value) in our code instead, the state would not be updated and therefore the code would not work. If we try to type our developer tools would display an error message stating that "name" is not a function and therefore cannot take in the parameter of "e.target.value".

In this example of code, we also set the value of our input field as "name" the input field would not let us type. It wouldn’t allow us to type because there is no way to update the state of “name” without the setter function. Thus, the input field would stay stagnant and unchangeable.

So, how does Squidward fit into this again?

Back to the Squidward time traveling analogy, I think about useState() as a way to take the current state (or value) of something and change it in a way so that in the future it can represent something different. Think of useState() as the elevator that Squidward gets on. Which then allows him to be exposed to the different phases of SpongeBob. The era handle that Squidward turns would be the event that is happening.

The initial state of useState() would be SpongeBob as his current self.

The kind of “SpongeBob” we would get would depend on the value of the event which we will get depending on the event (the era handle). The initial state of “SpongeBob” would change based on the time period (our e.target.value) the era handle (the event) lands on. If the value of the time period is the past then we would get Caveman SpongeBob.

However, if the value of the time period is the future we would get FutureBob.

Regardless of what era the handle lands on, there will be a change of the initial state and we will either get Caveman SpongeBob or future SpongeBob. The previous state of SpongeBob before the elevator era handle (the initial state) would be the regular SpongeBob that Squidward knows (and loves).

Keep Learning!

The analogy can be a bit extreme, but if you are someone who thinks visually like me, it may help you to visualize something. This connection allowed me to really picture what was happening and how to use useState() as a whole. If this analogy isn’t as helpful, I end this blog post with the wise words of a friend of mine who said that he likes to think about the setter function as “const variableName = ". This shorter way of explaining gets straight to the point, that when you use the setter function you are updating the previous value of the state. Whatever gets you to continue to code along and get more comfortable with useState() is what you should refer to as you continue your coding journey!