Common Mistakes That React Programmers Make
React is an awesome framework and it can will let you build beautiful application with much ease but just like anything, if you don’t use it correctly you can make a giant mess and you can make spaghetti code in react as well. So, let's get straight into common mistakes to avoid while using React and that will make you a better programmer in React.
Let’s figure it out which one of these mistakes you are making.
1. Inefficient Project File Structure -
Let’s start with a very first mistake and this is a mistake you make when you start building your project for the first time when you’re building your folder structure and you’re organizing your file and everything, there is no right way to do it if it’s working for you then it’s a good structure that’s how we should look at it because there are multiple ways to do it however there are some stuff that you’re not supposed to do, that would make things more painful, it would work but it would make things more painful. The first rule of thumb is if something is only going to be used by that component or that file then it should stay next to it.
For example – If you have a CSS file that only applies to one component then it should stay with it. Unit test if it applies to that component which usually is you should stay with it which means you have one folder with a component its unit test and itself. Anything that applies to multiple components should stay a little bit higher because they can access it much easier. If the component that is used inside that page is sometimes outside and In some other locations, which is really bad, and if you move stuff and stuff starts to break then you know that you have a bad folder structure to mitigate it. Whenever you create a new project there are multiple ways to organize your folder and you can also it google it like – standard folder structure for React.
2. Monolithic App -
The second mistake a lot of people make is that the power of React is in its components you can componentize everything however a lot of people make modern Monolithic applications which means making one page and they put everything on that page or even if they have components they have not componentized things enough.
For example – when you get a design you need to identify multiple things then, you need to identify your layouts your navigation your lower-level components which means like your buttons, input boxes, check box, and then you need to identify your fragments. Fragments are the one that is made of multiple lower-level components and then you identify those and then you can plan accordingly. Say ok, I have this page there are things can be reusable then create components ideally you want to component nice everything. So, they’ll be like one guy who knows how to write CSS and everybody else just write JavaScript so then the one guy builds all the reusable components and everybody just follows. There’ll be like a style guide with all the components and there will be documentation and rest of team would use it and that is the best approach. This way you can avoid duplicate code your application becomes very flexible and maintainable and that’s the keyword because if you have a giant monolithic application and if you say ok, I want to change this button green to yellow then you have to dig into the code to change many different places then you have failed to reuse the components also another gauge would be if you have a file that has more than 200 lines you know you are doing something wrong you should have some sort of gauge say ok, I should not write more than hundred lines of code in one file and you should create that rule for yourself and beyond that, you should componentize.
3. Redux to manage all the states -
With bigger React apps, many developers use Redux to manage global state. While Redux is useful, you don’t need to use it to manage every state in your apps.
If you have an app that doesn’t have any parallel-level components that need to exchange information, you have no need to add an extra library to your project. It’s recommended to use a local state method or useState over Redux when you use a form component and want to check the state of a check button every time it’s accessed.
4. Not having Unit Tests.
The first thing that ran in my mind when I decided to write Unit Tests is to decide on what to test in this whole component. Based on my research and trials, here is an idea of what you would want to test in your component. Having said that, this is not a rule, your use case may want to test a few aspects out of this list as well.
On a general note, if we are Unit Testing we must be performing tests on a dumb component(simple react component) and not a connected component(component connected to the redux store).
A component connected to the store can be tested both as connected component and dumb component, to do this we have to export the component in our definition as a non-default. Testing connected components is generally an Integration Test
5 - Leaving console.log Statements in Production -
This gotcha is controversial, but worth forming your own opinion on. Many of us debug our software using console.log() statements. But did you know that console statements are synchronous? Due to their synchronous nature, when left in your code, they can cause serious performance issues. The issue also exists with external debug libraries such as redux-logger.
One possible solution is to make sure no console.log statements end up in your production build. However, this is easier said than done. To help with this, you could install and set-up ESlint in your React project. ESlint is the ubiquitous linter for JavaScript frameworks. ESlint enables you to keep your code cleaner by enforcing several industry-standard rules for how you should write your code.
After that, you can add a no-console rule in your project's .eslintrc.js file and you’re done:
0 Comments