OK, so I've prepared this strategy guide here, which sort of represents the steps that you need to
take in order to to debug and find the source of your issues.
So that's really the point of debugging.
It's sort of to find that root cause.
So that's your main thing that you're going to be working through in this course.
And also just in your career, when you stumble upon a bug, you're going to end up being a detective
and following certain steps.
You're going to be you're going to be confirming that the bug occurred.
You're going to be gathering the clues that are going to help you find that bug, and then you're going
to actually find where that bug is in your code.
And then, you know, you're working toward finding that root cause.
So with that, we'll just get started with explaining this.
So, again, the point of this is to help you determine the root cause of that issue.
So that's really the hardest part, right?
When you find a bug, if you knew why that bug was happening, you'd be you'd be a lot and in better
shape to fix that bug.
Right.
But a lot of times we don't know why the bug occurs.
And that's where that source of anxiety and panic happens, because we don't know why it's happening
and we don't know how to fix it.
So once you figure out why it's happening or the root cause, then you're in much better shape to fix
that issue because you know why it's happening.
Right?
So this whole guide here is to just help you understand why a bug is happening in the app.
And I've seen a lot of beginners struggle with with a lot of these steps.
So they don't get past a certain point in this.
And it's really just about knowing the tools that you need to investigate and just being really resourceful,
like using Google and just doing a lot of research on what you're working on.
So let's start from the top here.
So first thing that you really want to do is confirm the bug.
So you actually want to reproduce that bug, whatever it is.
So if someone else points out a bug to you, you're going to want to see that you can reproduce it on
your end if you run into the bug yourself.
Of course, you've already reproduced it, but still, it's really important that you can actually reliably
trigger that bug.
So you're going to want to refresh the page and you're going to want to make sure that you can actually
see that same bug every time.
This is really important.
The first step just confirmed that the bug is there because sometimes bugs will be reported and there
won't actually be an issue.
And so you can weed that out quickly by making sure that there is an issue and that you have consistent
behavior.
Right.
You have consistent issue next.
You're don't want to gather the clues.
So once you've consistently reproduced it, you can now see what what is actually happening.
So what's the evidence that you're going to collect here?
The first thing you're going to do is you're going to see if there's errors in the console.
So this is really important.
This is the main source of that.
You know that there's an error.
It's it appears in the console, it's very obvious.
It's in red text.
And a lot of people will see this and they will just stop right there.
This is kind of where a lot of beginners will just stop right here.
They see the error and that's all they know.
They don't have any other knowledge of anything of what that error is.
And so they just kind of well, we're just report that error to me and say, I'm getting this error.
What's going on?
So what you can do.
So then you could step you could take that step further.
So after you you've you have that clue that there's an error in the console, you you can make an assumption
that there's a JavaScript bug or, you know, so that's really where those console errors come from.
Some JavaScript library, whether it's your code or a library, is throwing a JavaScript error.
And so that's that's the first clue that you can make if you see an error.
Now, if you don't see an error in your console, it means that you could have any number of things
going wrong.
You have so common thing is that you have incorrect components.
So you have your react app and your rendering, let's say the wrong component or a missing component
or some button doesn't do the right thing.
That's, you know, some you're clicking on a button and it's not it's not giving you the expected result
that's could be due to you, like I said, a wrong style.
It could be a it's a rendering issue, right.
This type of issue.
And it could be related to an unexpected react state.
So let's say you have a state that's like hide this button and, you know, it's not being hidden.
So that could be a result of the state being wrong in the app that should show that button.
Or it could just be the button itself, not hiding itself correctly.
So in any case, this would be a rendering issue.
And it's you know, it could be HTML.
You could have you couldn't you know, you so you have the wrong button HTML text or you have the wrong
button attribute on the HTML, or you could have the wrong access so you could have the wrong, let's
say display none is C property, you could have the wrong access.
So this is just, you know, my two ways that I'm going to be talking about.
These could be a rendering issue or it could be a JavaScript issue.
And I've also split those out in here as an error shown and then no error shown.
So this is just how I'm breaking it down for you to make it easy.
There's obviously any number of.
Hours, you could have a slowdown, you could have a network issue, you could have something like that,
but those are less common.
We're going to talk through the most common issues or errors here, which is you have an error which
would be determined by the stack trace stack traces that function stack that is going to show in the
error.
The error is always going to give you the source of that error, which is the biggest clue of how to
actually fix that.
Now, like I said, if you have a rendering issue, you're going to have less evidence.
It's going to be harder to debug that.
But I'm show you how to do that in this course with the ability to inspect the elements, inspect the
elements on the page to find where that source code is of that component.
And again, I'm actually at a search for files for those suspected components or access classes.
So common thing to do is when you see a button or something or let's say a header, something wrong,
you're going to want to search your app for that component.
So, you know, searching your files for that component, searching for CSFs classes, because with
a stack trace, you have that exact trace of where that error is coming from.
With when you don't have the stack trace, you're going to be forced to actually do some research into
the code and see where that element is happening or where that element is being rendered and how that's
being rendered and what's going on with that.
But really with this section here, the key thing is to find the code.
So you're trying to find the code that's causing the issue.
Right.
So if you have a component that's, you know, a person image or a person page or a profile page, let's
say you can know that.
And there's a there's a react component called profile page, you can make that assumption, OK, this
error is coming from this file.
And then if it's on the the person image, you could say, OK, it's it's person image.
That's the code that's causing the issue.
So the purpose of this section is really just to get you to find the exact files and code.
So code or functions or classes inside of that file that are causing the issue, then you're going to
actually do some more research into why.
So the key thing here is you're going to try and you need to be able to explain why that bug is happening
in order to move forward with fixing it.
So the split here is the bug is in your code and the bug is coming from an external library.
So let's say you have some JavaScript, simple JavaScript error in your code.
You've traced the stack trace down to your code.
You can make that assumption here.
It's in your code because you've written that code.
It's in your file.
And you you're going to then proceed with checking your spelling, your syntax, making sure that you're
writing good JavaScript, and then you're going to want to dig deeper into setting breakpoints and examining
that states you're going to be setting breakpoint.
You're just looking around and confirming the variables and data that's defined in that state.
And that's going to really help you because you're going to be able to make assumptions.
OK, well, the states wrong.
So that's why it's not rendering the right component or whatever it is.
And then also, if let's say you have a successor HTML issue, you're going to want to use the chrome
dev tools again to look at that success and then see what success trace that back to your classes,
your success classes or style components or whatever you're using, and then make the assumption about
what styles are being correct or incorrect.
They're.
So the bug is coming from the external library, you can make an assumption that it's coming from an
external library if, let's say, an external library during an error or if you don't know what's wrong
or there is some kind of issue with some component that you're installing.
And, you know, a lot of times you that won't have a stack trace, nothing will be wrong with, you
know, there won't be any errors, thermosphere rendering issue.
So a lot of times you will have to debug external libraries.
And that's can be that can be really challenging because it's not your library, it's not your code.
And you have to actually research that so you can research that library and then you're going to Google
the error message.
That's the most common thing to do.
This is a really good practice.
If you see an error, even if you you already think, you know that error is it's always good to, you
know, research it again just to see that error.
What people are saying about that error, a lot of times you could if you're in a library.
So if it's an external library, you can actually search the GitHub issues for that library and find
see if the people are talking about that error there.
But usually just Googling that error message is going to give you what you need.
Let's say it's a react error you could especially react to.
Errors are going to be a lot of documentation, blogs and things about errors in react.
So really great practice to just Google the error that you're getting rather than try and track it down
yourself.
Just quicker way to get an explanation of that.
And if you research the library, you may already know a lot of things about it and it should be obvious
what's happening.
For example, if you if you don't know what react is an error, telling you about state is not going
to be very helpful for you.
So that's why it's really important to see the library.
Also, if you have a component that has a lot of options, you're going to want to research the documentation
to see the right options to pass in.
And that's where the next thing comes in is try a clean example from the documentation.
So if if you have some component in your app and you have no idea where that component came from, you
can research the library that it came from and then take an example from their documentation and put
it in your app or match it up with your code and see what's wrong and remove attributes on that component
to actually get it to a cleaner state.
Right.
Get it to a cleaner point where it actually works.
And that's kind of the really the last step here is, you know, good.
A good thing is to to get your code back to normal as quickly as possible so you don't want to be fighting
with a bunch of options or things that you've no idea what's going on because it's external code.
You are you're always able to, you know, remove code inside of your app and then slowly add back in
the problem code.
So the last step I have here in the external library is to debug the source code of the library.
So this is something that you're going to do pretty rarely.
But sometimes the component will be so, or sometimes the library will be really obscure and there won't
be any documentation on it.
And you'll actually have to go in and set breakpoints in that library and see what's going on or read
the GitHub source code and see what's going on.
And then you'll you'll know maybe you've got a hidden attribute or something that's not in the documentation.
This is really a skill that you're probably not going to need to do as a beginner because you're going
to be going to be using good components as a beginner.
You're not going to be really trying to debug advanced components right away.
But if you're using a lesser known library and you really want to know what's going on and you're not
sure what's going on in your code, you could debug the external code of that library.
Also, this is the supplies, the APIs as well.
So a lot of times you'll have a back end.
So you have a backend developer and or an API that you're calling and that network request will return
an error or something like that.
And so you'll have to debug that API.
And that's even more difficult because, well, it's actually more common than an open source.
They're both equally common, right?
It's just external code.
That's not your front end JavaScript or react code.
It's coming from a back end or another react library or something.
So either way, same steps apply.
You're going to want to research your own back end APIs, talk to your back end developer, try and
get information about what's going on with the data.
OK, and then if you can't track that down, then you can always revert back to a working state, so
always try and revert back to something that actually works and then slowly add in that error or, you
know, the error state or the problem code.
So, like I said, a working state can be an example from the external library or just a simpler component
that, you know, works.
So that is the debugging strategy guide.
We're going to be using this throughout the course and you can download this and use it for your project.
So I hope this was helpful.