React Project Structure
Since it’s release in 2013, Reactjs has become more and more popular among web developers around the world and it’s being used in a variety of different projects including web applications and Progressive web Applications.
While respecting software development principles, different developers and teams who use react for their projects utilize it in their own way according to their needs.
Is there a “standard” file structure or architecture for react projects?
So how do we structure our react apps?
while react doesn’t have a standard unified structure it’s always better to organize your files and codes to avoid confusion and prevent wasting your precious time looking for a specific piece of code.
according to my experience working on many different projects and reviewing other projects codes here are some options that you have while planing your react project:
– Page Based Structure
React apps are basically SPAs and in order to have multiple pages we have to emulate a multi page behavior using routing and particularly by using react-router library.
In this approach we break the app into multiple files based on these different routes and all of their sub components and related functions are in that route’s related file, and put reusable components in another folder like “elements”:
the advantage of this structure is that it enables a team to assign each page to one of the members of the team and all sub components and functions related to a route are available right in that rout’s file.
tip: categorizing pages by folders can make the app’s file structure cleaner and more manageable.
– Component Based Structure
For highly large scale applications modularization is vital, while the previous structure works for most projects sometimes teams might need to break the app into even smaller parts, that’s when this method comes in handy.
In this method every component has it’s own style and test files inside it’s corresponding folder instead of one monolithic css or scss file, and all sub components have their own folder and files too (like “ProductItem” in below example) this makes it possible to use each and every component independently anywhere even in other projects.
│ index.js │ package.json │ ├───assets ├───components │ ├───Button │ │ Button.js │ │ button.test.js │ │ header.scss │ │ │ ├───Header │ │ │ Header.js │ │ │ header.scss │ │ │ header.test.js │ │ │ │ │ └───Navbar │ │ Navbar.js │ │ navbar.scss │ │ navbar.test.js │ │ │ ├───Main │ │ │ Main.js │ │ │ main.scss │ │ │ main.test.js │ │ │ │ │ ├───Calendar │ │ │ Profile.js │ │ │ profile.scss │ │ │ profile.test.js │ │ │ │ │ └───Profile │ ├───Page │ │ Page.js │ │ page.scss │ │ page.test.js │ │ │ └───Products │ │ Products.js │ │ products.scss │ │ products.test.js │ │ │ ├───ProductFilter │ │ ProductFilter.js │ │ productfilter.scss │ │ productfilter.test.js │ │ │ └───ProductItem │ ProductItem.js │ productitem.scss │ productitem.test.js
these two example approaches are quite common but with minor differences based on the scale of applications.
Remember that the best project structure is something that you are as comfortable as possible with, both in short term and long term, when you will need to get back to your code to fix something or reuse a component or a functionality, that’s when an organized and proper project structure pays off.