Everyone loves a good list, myself included. In this article, I will share 10 principles that you can add into your programming toolbox that will result in you writing better React applications, sounds good? Let us begin!
Naming Is Very Important
Did you know that developers spend more time reading code than writing it? When code is hard to understand and difficult to reason about it wastes time. Bad code results in developers needing longer to understand it. The best way to make code easy to understand is by using good naming conventions.
A common objection to writing descriptive names by some Javascript developers is that the extra character length increases the bundle size. Do not forget when we write code within ReactJS it is compiled. During compilation, your code will be obfuscated and changed outside of your control. The ReactJS you write will not mirror what the browser reads. This bundle size excuse is usually a myth. The real reason for most people not wanting to write descriptive names if they are honest is laziness. It takes longer and more effort to type long names. Great developers don't use excuses and you should follow that rule! Assuming you are sold on the importance of naming, lets cover the most important areas for good naming conventions:
Use descriptive names for methods, variables, parameters, and arguments
Use capital letters for component names, so 'MyComponent', not 'myComponent'
Avoid acronyms in names unless everyone on a team understands them, even then favour names a new developer to the company would understand
Name your components after their function
Do Not Repeat Yourself is a mantra that I try to adhere to at all times. Duplicate code means wasted time writing duplicate unit tests. Duplicate code will result in wasted maintenance time later on. Duplicate code increases the chances of bugs due to accidental and unintentional nuances. When thinking about duplication, a good rule of thumb is that if code is duplicated in three places you should invest the energy to refactor it.
Ask For Help
Asking for help is a double-edged sword. Every time you ask for help you rob yourself of an opportunity to hone your analytical troubleshooting skills. Trying to solve your own problems will give you confidence and help you move up the career ladder. When solving an issue you need to give yourself a time limit. Wasting days on a problem that a teammate could have helped you with is also not a good use of time. So you have a trade-off, being independent and not wasting time.
From my experience, if you are more junior you may be tempted to give up too soon. For those readers, I suggest after say 3 hours when you are really stuck. Give yourself an extra 45 minutes and really think of alternative solutions. If you have been stuck on something for around half a day, ask for help! If you feel confident you have done everything you possibly can to solve a problem that is good. Out of all the teams, I have worked with, it is very rare that someone will not want to help someone out. It is frustrating working with people who have obviously spent given up researching as soon as they hit a snag.
Keep Your Components Simple
Another ReactJS truism is that the smaller the component, the easier your life will be. Testing that component will be simpler. The chance the component can be reused increases. A smaller component can usually be optimized for performance easier. Life is great!
As a project evolves it is easy for a component to accidentally grow to ungainly size. This tends to happen when the responsibilities of a component grow. Normally when a component starts to get big (over say 200 lines), if you take a step back it is usually obvious where it can be split into smaller components. Applying techniques like the higher-order component pattern or the container/presenter pattern will improve things
The Boy Scout Rule
The boy scouts have a motto. “Always leave the campground cleaner than you found it.” If you encounter a mess you should clean it regardless of who made it. When you work within a code-base if you apply a constant rule for making small incremental improvements on every pull request the code will constantly evolve and improve.
The longer you leave a code-smell within the code-base, the harder it will be to remove later on. Constant never ending little improvements will have a drastic improvement on the quality of your code-base
Separate Stateful Logic From The JSX
It is very easy to overcomplicate components. Imagine you have a need to call some data from an API and render the data within a list. One way to solve the problem would be to build a single component that would perform the fetch and render all the JSX. This approach would work but the component would be very brittle. The JSX could not be used anywhere else without the data-fetching logic present.
A better way to handle component architecture is to apply the container/presentation pattern. In this approach, the API code is wrapped in another component. The JSX is then added in a very simple presentational component that has no/minimal logic within it. Following this pattern will result in less code and more re-use!
Favour functional components
Favor writing functional component rather than a class component will result in cleaner code. As of React 16 and the introduction of hooks pretty much anything you can do within a traditional Component or PureComponent you can do within a functional component. Leveraging useEffect and useState you can add state and life-cycle methods.
Test Behavior Not Implementation Details
Have you have ever worked on a project where you need to make a small change? The change is simple, it takes less than 10 minutes. When you run the applications unit tests things go to shit. The change has resulted in numerous failures. You then spend a lot more time fixing the tests compared to the original 10-minute change. If this has ever happened to you, chances are you have written tests that are testing implementation rather than behavior.
Imagine you have a button component and you would like to ensure the correct label is displayed. In this scenario, you do not care what props are passed into the components, or even how they change. All you want is a test that ensures the label works. These types of tests can be challenging to get working using 'Jest' and 'Enzyme'. In these situations, it is better to use a library like react-test-library.
Using react-testing-library you write your tests against the components outputted DOM nodes. This decoupling of tests from props will make your code a lot less brittle and easier to maintain. Writing tests like this will be less painful and will mean you are more efficient. If you have not come across react-testing-library. Happy Coding!
