5 React Good Practices

5 React Good Practices

What's up, everyone!? 🤙

Recently, I'm not that active here, but this is due to a lot of work that I have 🤓 I'm working on a couple of projects on which I will share more in near future (one of the projects is a game build with React Native - siiiick! 🤯).

Ok, let's get back to the topic! 5 React good practices! 🔥

#1 Remember to keep your components small and function-specific

I think we all have been at least once in a project that is a total mess when it comes to its file and folder structure. This uncontrolled mess can be changed by keeping your components small and dividing them by a logic/function that they handle. A single component should render just a specific element of your page or handle particular behavior. This approach will help you in keeping your code fresh and clean!

Also, it will help in better maintaining your tests, so it’ll be easier to catch a bug and most importantly it will help you and your co-workers to understand easier the code you wrote (especially when you go back to it after some long period 😜 ). As John Wood once said:

image.png

#2 Consider using (or not 🤔 ) DRY principle when creating methods

One of the popular principles out there is DRY. It is recommended to use everywhere, like literally everywhere. Even if you ask your neighbor Steven, he’ll also recommend it to you. If you’re not familiar with DRY, then let me quickly explain it. As you have already seen in the title DRY means Don’t Repeat Yourself. Simply said it’s a principle that encourages us to create reusable functions, so they’ll be not repeated within our code. The opposite of the DRY principle is WET (Write Everything Twice or also known as Waste Everyone’s Time). It is usually trashed, by others, because it encourages you to write duplicated code.

Also, some time ago Kent C. Dodds presented a new “principal” (it’s more like philosophy) called AHA (Avoid Hasty Abstractions). This “principle” states that “you shouldn’t be dogmatic about when you start writing abstractions but instead write the abstraction when it feels right and don’t be afraid to duplicate code until you get there”. I think it’s worth checking it out. Link below: kentcdodds.com/blog/aha-programming

image.png

#3 In most cases try to use controlled components instead of uncontrolled ones.

I’m going to start with a quick explanation, as maybe some of you are wondering now "what the hell are controlled and uncontrolled components? 🤔" Ok, so both are used only in a form element, and being more specific they are used in the input, textarea, and select elements. Controlled components are the ones that value is maintained by React’s local state, so in this case, we’re achieving a “single source of truth”. On the other hand, uncontrolled components are components that DOM uses itself to handle data from a form. Both solutions give you the possibility to have one-time value retrieval and validation on submit. However, only controlled components are the ones that should be used in the case when you need instant field validation, conditionally disabling the submit button, enforcing specific input format, or for example creating dynamic inputs. The only case where usage of uncontrolled components is a must is an input element with a “file” type. In this element, the value can be only set by a user, and not programmatically.

#4 Write tests for your components

You’ve got an error and don’t know where it comes from? I think that’s a good reason to start writing tests for your components 😜 .

Well written tests are not only preventing you from having bugs but also improves the quality of the code. Moreover, it will provide you documentation as you will have every functionality of the method described. Also, it will simplify the debugging process as if a test fails, then only the latest changes made in the code will need to be debugged. I can keep writing more and more advantages of writing tests, but this is not the case here. Just remember to not be lazy and start writing those tests! 😜

image.png

#5 Use React PropTypes or TypeScript

Type checking alongside tests is very useful to keep your code out of bugs 🐛 . It is used to make sure that data you receive is valid (ex. method that should take as an argument a string value, didn’t receive an object instead). Also, using type checkers you create some kind of documentation for you as you’re defining what type of data the function takes as input and what type of data it returns as output. That helps later on for example when doing refactoring or just to help other co-workers to understand your code better! For type checking, you can use PropTypes, which is a small library for checking React props and similar objects, but if you want to go total badass 🤟, you can use TypeScript, which is an open-source programming language.

I will do a separate article on those two, but the difference that you should know for now is that PropTypes is type checking at runtime and Typescript validate the types at the time of compilation.

image.png

The End 🥺

That's it for today! 🤓 Feel free to drop a comment or like if you found this post useful! 😊 Also, let me know if you would add something else to this list! 🤙