How I did(n't yet) become a Senior React Developer

If like me, you are or have been one of the many developers who still have a hard time understanding the difference between a junior and a senior react developer, that means you're probably still a junior. To clarify this, here is a bunch of best practices that i learned during my journey to become a Senior React Developer.

• Avoid Inline Event Listeners

One of the biggest mistakes me and almost all beginning developers make is using inline event listeners. During big projects, in my case Bard Goblin (my main project), you'll find that using inline event listeners can really mess up with your code, to the point that as the project escalates, even you can't understand it. That's why it's considered a bad practice. And if it wasn't enough, it goes against some principles, such as Don't Repeat Yourself(a very important principle that I've learned too), in case if you needed to repeat this code block elsewhere.

To see what I'm talking about, this is an example of the difference between one code using best practice and the other not:

• Big Components

Another problem that I've faced on big projects too and many also face was in the creation of large snippets of code, how should I code them? Should i separate it, won't it get confuse? That's what I thought and you probably thought too. Since React is based on components, I realized that it doesn't make sense to write huge code with lots of responsibilities and lots of unnecessary things all in the same place.

Components let you split the UI into independent, reusable pieces, and think about each piece in isolation.

When a component starts to have several responsibilities and starts to get extremely large, in addition to going against its principle, it becomes difficult to understand, refactor, and test.

• Component Folder Structure

Following the same line of reasoning, maintaining order, single-responsibility and easy to understand, one of the things I realized is that we should avoid exporting multiple components from a single file. Although, it seems the fastest, I just realized it wasn't the best option.

To avoid this, you can create a folder for each component thus facilitating their identification, understanding and refactoring, see an example below of how I would solve this problem:

Multiple Export

One export per file

• Prop Plowing

Some time you probably had a component that needed to receive a lot of data from the same place and it probably ended up becoming something like this:

To avoid this, you can make use of Spread Operator(highly recommend you to learn how to use and abuse of that operator), making it easier to read, understand, develop, and mainly, as i already mentioned before, Don't repeating yourself:

In general, the best advice i could give to you is always try to apply as many good practices as possible, so that your code is accessible, readable and understandable to everyone, after all, how a code can be good if you're the only one who can read it?

Keep up the good working!