Structuring Reactjs / Nextjs Applications
In a collaborative environment, while building web applications, the overall project structure and directory management could be a great deal to how your teammates would love working with you on the project and also how it makes them think less navigating your project. Having a signature project structure would also make it fun to work continuously with folks on multiple projects.
In the context of React, oftentimes beginners create dangling components, and it is understandable because we are just navigating how things work. But don't get too comfortable though. It is quite easy to fall into this trap if you find yourself mostly working alone, but it becomes a whole new world when someone else needs to read your code when you are not available and they can't proceed because the project structure is pretty bad.
Whenever I think of React, what always comes to mind is "building re-usable user interfaces". Having this in mind keeps me in constant checks when breaking down a design into a bunch of reusable components. By so doing, anyone can get on my projects with little or no supervision from me and they can have some level of understanding on how to navigate.
In this article, I would introduce you to how you can structure your React projects to improve collaboration.
Before you begin this tutorial you'll need to have a basic understanding of the following:
- React components
- Higher-Order components
My typical React app structure.
This could be called the flat structure. Mere looking at it, you can have a conceptual overview of where to go to find what. I am mostly concerned with the 'src' directory because this is where most of the work goes down.
Assets contain styles sheets and any asset that can be used in the project that doesn't URL reference. Are you curious about the 'scss' directory? I have well-explained detailing here.
Components directory contains all UI elements e.g button, form elements, layouts, etc. As a frontend engineer, when you closely observe designs across the project, you certainly will note the following
- UI elements that are used in multiple places (sometimes with similar or slightly different) e.g buttons, inputs, avatar, links, etc
- Re-occurring SVG elements, etc. edit-icon, delete-icon
At least one or two common layouts. Think of the layout as an overall housing for all these UI elements.
Retroly.io's landing page - Layout 1
Retroly.io's dasboard page - Layout 2
Closely studying "Layout 1", it has a footer, different navigation links make up on the Header and also different backgrounds when compared to Layout 2.
With the above recurring patterns, I have come up with a breakdown of all components into
- blocks: components are just any react component (controlled & uncontrolled) e.g Form, TextArea, Input, Card, etc
- shared: components that are shared among multiple layouts e.g Footer, Header, Button, Avatar, Progress, etc
layouts: components here are High order components that house all other building blocks e.g DefaultLayout, AlternateLayout, AdminLayout, etc.
vectors: components are mostly SVGs e.g Icons, logos, illustrations e.t.c. I find it easier to re-use SVG elements by making them React components
Bhanu Teja Pachipulusu has an article with a different approach here
Using React Components as re-useable SVG.
vector folder structure
Constants directory contains a single file with globally accessible constants like Redux actions, statuses, enums, etc.
Services directory contains resources that can be used as service to supply data to your application e.g API Client, dummy JSON data, etc. Using Axios in React, you can declare a reusable Axios Client.
A basic Axios client.
Utils directory contains utility or helper functions. The functions here are functions that can be used anywhere in the application. For example, a function that returns a unique id that can be used as a key for react components, a function that returns the user token (this could be helpful for authentication), or a function that returns user's data.
One fun fact is that this folder structure works well with concepts like CSS-modules, Atomic CSS, Block-Element-Modifier (BEM).
Duomly has an awesome read on more approaches too here