King Somto
27 Aug 2021
•
3 min read
Building react apps is hard but what is also harder is maintaining standards and a good workflow while building the react application mainly because of time constraints. We usually do some things that make it hard to either debug or read our code later on in life and that's bad. So in this article, I am gonna show you a list of things I did wrong when learning how to build React applications. Most of these points can be used in things like Angular and Vue.
So one big mistake we make once in a while would be to have a central CSS file usually our `app.css` and just put all our styling inside that, this is very bad mainly because when the project starts getting large styles may start conflicting an example would be.
<Component1 className='test1' >
<p>
hi
</p>
<Component2 className='test2'>
<p>
Hi again
</p>
</Component2>
</Component1>
The example above shows a situation of having a component component1
nested inside component2
a style affecting component1 p tag
would affect component2 p tag
because they share similar CSS files, this could bring up issues and make it hard to debug issues.
A solution would be to use the styled-components
package that helps users isolate their styles in respect to the components.
So this is a no-brainer, having large component files gets annoying not just for you but other developers that may join your team in the future might have a hard time debugging components you built previously. Dividing components should be done by tearing down a user interface to the most basic building blocks or components that can form a single unit and have independent logic, doing this reduces the complexity of the component and provides an easier way of knowing if something goes bad in the component.
An extra rule to make would be if a particular div
requires more than 2 or 3 functions to work it would be best to turn it to its own component or anything repeated more than once in a component like a special button or special text.
We try our best to have components or files that are not large, a good way of doing this is to declare util functions that are used across multiple components and export those functions so that the components can access them, this really helps to remove repeated codes declared across multiple files or components.
During development, we run into issues like parent components needing to update states to cause a re-render during the app's running process, so what we initially do is that we create a function in the parent component and pass the function that interacts with that component.
function App() {
const [state, setState] = React.useState({
name: ''
})
return (
<div className="wrapper">
<p>{state.name}</p>
<Child grandChild onChange={() => {
setState({
name: 'Somto'
})
}} >
</Child>
</div>
);
}
const Child = ({ grandChild, onChange }) => {
return <div>
{grandChild && <Child onChange={onChange} />}
</div>
}
The example above passes a function call into a component that then again passes that component to its child component, this method of passing functions works but in a case that the component for some reason does not pass the function or the passed function is commented out we would not be able to call it and we have to start going through a long hierarchy of components to find which parent component does not pass this function, this can be hard to debug, one way avoiding this is to use the React context provider
which shares state with all the children component it has in the application.
It's a bit mundane but it's always a good practice to comment on your code so that people that pick up your codebase can easily hop on the codebase.
As your app grows you can catch some bogs by using prototypes for type checking, adding prototypes also helps people maintaining your codebase to know the types of values your component can take.
So we were able to go through things that may not always be a good idea to do when building a react application but at the same time for debugging and maintaining purposes. The rule of thumb here is basically to always write code like the person who is going to maintain it is a violent psychopath that knows where you live.
Ground Floor, Verse Building, 18 Brunswick Place, London, N1 6DZ
108 E 16th Street, New York, NY 10003
Join over 111,000 others and get access to exclusive content, job opportunities and more!