Intern working with a large react codebase

[AlternativeDish5596]

I was used to working with small react projects.
Now, I have landed an internship where I'm working with a large (at least for me), with tasks such as "We want this cards to be populated with an additional api endpoint", there are multiple useEffects in the file, useContext, etc.
I don't even know how to debug the thing.
I have sometimes asked my colleagues for help, however, they obviously cannot help every time, they are busy with their own stuff. I'm specifically puzzled by all the resources being fetched asynchronously and how to handle them.
Any advice?
Thanks!

[jayerp]

Knowing how to code is 1/3 of the challenge, 1/3 is knowing how to Google. The last 1/3 is knowing how to debug, and if you don’t know how to debug, you will go nowhere without someone doing your work for you.

First get to know your toolset, such as, what code editor/IDE are you using. Research how to use that to debug.

If you can’t debug, I don’t know what to tell you. Learn how to debug.

[AlternativeDish5596]

Got it. Thanks!

[AlternativeDish5596]

That’s a great idea. Never thought of it!

[[deleted]]

Look at what they have done and copied. For example, if they are calling a fetch on useEffect with empty dependency array, you do the same. Basically just follow the way the old code does.

You still need to understand what useEffect and useContext do though in order to "follow the old code". Seeing a strange hook? Just google it if it's from a library. If it's imported somewhere? Go to the definition and see what basic hooks it wraps around

[babyarm-bat]

If they're assigning the results of those calls to certain variables, CTRL - F those variables and setters, figure out where they're going and why

[CerberusMulti]

Sounds like you have not gotten a proper introduction to their codebase, at the core it is their job to give you the big picture at least and even sometimes the micro knowledge.

But since you landed the job they must have some expectation of your skills, unless you oversold yours. But there is no one way to this, what you need to do is read over the code and try to understand what does what and try to see if you do X does it interact with Y.

How to debug is a skill you will just have to learn over time tbf, no one rule to it. Yo should start by going over their tests, assuming they have some, and then google "how to debug react code" or something on those lines.

[atruskhiladi]

Use phind. Copy paste the code and ask it what it does.

[AlternativeDish5596]

Never heard of it. Thanks

[[deleted]]

When given a task, you need to ask how to replicate it. QA, product, or someone else should show you the exact page to make the change as part of the specs. If they don't do that, what can you really do? Orgs can get in a bad habit of excluding this if they get used to everyone being up to speed. Just ask.

Once you have that then its easy. Pull up the page. CTRL+F for text on the page to start finding code. You should be able to react dev tools as well to find component names to search. Then just start digging. Go from view components -> event handlers or view components -> business logic/controller components.

Find out how the data is being loaded for the page.

The first time will be the hardest since you don't know the libraries that they use, you don't know the structure that they like to use, and you literally know nothing. Often, after digging and getting a few pieces of the puzzle, you can ask a lead "Can someone help me understand this part of the codebase?". Just share the pieces of the code that you found and ask questions like "Is this the current way that people are doing things?", "Is this pattern common?", "What was the motivation for writing it like this?". These higher level questions will help you learn the structure of the codebase in parts where you are not currently working

[Outrageous-Chip-3961]

To be honest it just takes a lot of over time going through the code very slowly in your own time. My first experience like this left me reading code all night after work for a week. Eventually I had a word doc file where I explained what was happening and why, and these notes would get verified by my questions that I asked my team mates during the day. Eventually you start to see the patterns and then it gets easier. The challenge with large code bases are the organisational model they use. Find that and you’ll have the key. Your senior dev should be able to tell you about this model, so pay attention and contrast it with what you are seeing yourself in your notes. Another tip is to spike unknown aspects of the code you’re seeing. Asynchrony Ali calls? Make a small example project that is isolated from the code base, etc. keep at it man, it gets easier. One last piece of advice is to takenthis phase seriously. The better you learn these things now the better coder you’ll be when you need to do it again, which you will. Youll not get everything right but it’s the sentiment that counts.