Organize large React Applications like this

Hey there guys, Welcome to this blog. In today's blog we'll be going to see how we can organize our large ReactJS Apps, so as we've seen that most of peoples are now using ReactJS as there primary frontend library to create different kinds of websites and web applications.

Also, One of the best features of React is how it gets out of your way and is anything but descriptive when it comes to file structure. Therefore, you’ll find a lot of questions on Stack Overflow and similar sites asking how to structure applications. This is a very opinionated topic, and there’s no one right way.

In this article, I’ll talk you through the decisions I make when building React applications: picking tools, structuring files, and breaking components up into smaller pieces, etc.

Folder Structure

Let's view the folder structure of the react application:

As you can see in this image, there's a folder structure of your react app.

Well, So your all the code is present in src
To keep things organized, I’ll place all application code in a folder called src. This contains only code that ends up in your final bundle, and nothing more.

This is useful because you can tell Babel (or any other tool that acts on your app code) to just look in one directory and make sure it doesn’t process any code it doesn’t need to. Other code, such as webpack config files, lives in a suitably named folder. For example, my top-level folder structure often contains:

• src => app code here
• webpack => webpack configs
• scripts => any build scripts
• tests => any test specific code (API mocks, etc.) Also, the one file named index.html, package.json, and any dotfiles are configuration files.

React Components

Once you’ve got a src folder, the tricky bit is deciding how to structure your components. In the past, I’d put all components in one large folder, such as src/components, but I’ve found that on larger projects this gets overwhelming very quickly.

The one thing to get this understanding easier is to group the components, it means categorizing the components based on their commom properties like where it should be & why it should be there makes the component look clean, neat, and understandable. For example, you have an component that renders the buy product cost, let's call it BuyProduct, you might simply prefer to use it as Product, cuz you'll then import it from the Buy folder.

import Product from '../buy/product
// VS
import BuyProduct from '../buy/buy-product'


Prefer JSX Extension

A lot of people name React components with a capital letter in the file, to distinguish them from regular JavaScript files. So in the above imports, the files would be BuyProduct.js, or Product.js. I tend to prefer to stick to lowercase files with dashes as separators, so in order to distinguish I use the .jsx extension for React components. Therefore, I’d stick with BuyProduct.jsx.
You can enforce this .jsx convention using a rule from eslint-plugin-react.

Prefer using Prop-Types

React allows you to document the names and types of properties that you expect a component to be given using its prop-types package.

By declaring the names and types of expected props, along with whether or not they’re optional, you can have more confidence that you’ve got the right properties when working with components, and you can spend less time debugging if you’ve forgotten a property name or have given it the wrong type. You can enforce this using the eslint-plugin-react PropTypes rule.

Conclusion

Hope you have understood ow you can manage your larger react applications with this short & simple article. One of the best features of the framework is how it lets you make most of the decisions around tooling, build tools and folder structures, and you should embrace that. This article has given you some ideas on how you might approach your larger React applications, but you should take my ideas and tweak them to suit your own and your team’s preferences. Let's connect on Twitter :D