Pro REFACT for REACT

Creating applications that work is easy, but developing applications that scale is challenging.

Spending time on only making things work is one of the biggest mistakes a lot of developers make, as there is a difference between spending time making things work and utilizing time to develop things that scale. Preferring an easier solution instead of using a better approach is what leads to Technical Debt (an additional implied cost that is required for refactoring and reworks). So,

Focus not only on designing and developing a User Interface But also on designing and developing your Codebase.

In this article, we will be discussing Pro Refactoring Tips for React that makes our codebase more readable, scalable as well as manageable.

When it comes to creating components, there is no one way but there is a better way. For managing and organizing components, we have a components directory within the src folder.

Directory Structure

Suppose we need to create a Modal component —

  • Some developers will prefer creating a Modal.js or .jsx file within the components folder.
First way
  • While others will prefer creating a directory named Modal and within the Modal directory Modal.js or .jsx file.
Second way

Now, there is absolutely nothing wrong with the above-stated approaches, but for a cleaner architecture, we can make sure of three things—

  1. Use the .jsx extension over the .js extension, as using the .js extension doesn’t make it explicit that we are working with React.
  2. Never create a component file right within the components folder (1st way), because as the no of component grows your components directory will get overcrowded. Instead,
  3. Create a Modal directory with an index.jsx instead of Modal.jsx file.

Now, the benefit of creating the index over Modal.jsx file comes while importing the component—

Earlier
Current

As module bundlers always look for index files within a directory by default if a file name is not specified.

Suppose within our application we have a container or a page, that makes use of many components. For example —

As you can see as the number of components that are required increases the number of import statements also increases, which will eventually make our file congested.

In order, to tackle this issue we can create a separate index.js exporter file right within the components directory like —

And within the file —

What this file is doing is exporting the default export from these components as a named export. and now we can easily import any number of components with just one import statement —

Another essential tip that you can use is to organize your export and import statements alphabetically. (Notice in the above two code snippets).

Destructuring is simply a way of extracting data from a data structure. Suppose we have an object —

const user = { 
name: "Alok Sharma",
age: 21
}

Now, To access the name or the age property, we have to write —

console.log(user.name, user.age);

As the number of properties within an object increases, we have to repeatedly use the user namespace for accessing a property or we can make use of destructuring as —

const { name, age} = user;
console.log(name, age);

Now, To make components reusable and configurable, React uses something known as props (properties passed from outside) —

Behind the scenes, React creates an object named as props with all the attributes passed to the component mapped as key-value pairs i.e. —

To access these props within the component —

Now to avoid the repeated usage of the props namespace, we can use destructuring as —

There are many ways of styling a React component. One of the very popular approaches is to use the styled-components module. The only problem with using the CSS-IN-JS approach is that it makes our files overcrowded as structure, functionality, and stylings are written within the same file.

A better approach would be to use an external stylesheet for styling your components. When using this approach we can import the external stylesheet in two ways —

1st Way

The problem with using this approach is that our styles are globally exposed. i.e. Suppose the index.css file looks like —

And we have used the same className button within another component like —

Then the same button styles are going to apply to this Button component as well because, after module bundling in production, we will only have one .js file and not different components, So this way it can easily cause styling conflicts in larger projects. (Use this approach only in the App.js file for providing global styles).

Moreover React is component-driven. A component is a piece of code that is reusable, manageable (small in size), configurable (props), and modular.

Modularity simply refers to the degree to which a component can be developed in isolation without affecting another component.

As the above approach is affecting the behavior of another component, it is not modular.

To overcome this issue we can make use of something known as CSS or SCSS modules. To convert the above CSS file to the CSS module, we simply have to rename the index.css file as index.module.css. Now we can import and use our styles as —

What happens behind the scenes is the module will create and export an object with all the classes as key-value pairs —

{ 
modal: "modal",
button: "button",
}

which allowed us to access these classes with the classes namespace (standard name) as —

<div className={classes.modal}></div>

Now, this approach doesn't expose our styles globally and hence makes our component modular. Moreover, if we want to take it one step further we can even destructure these classes object as —

import { modal, button } from "./index.module.css";

That's it for this article, if you find this article helpful just do let me know. Stay Tuned!

Web Developer