There are a lot of different ways and approaches for creating a concrete project file structure for different coding frameworks. Today I’m going to bring you an approach that I’ve been using and structuring through my years in the industry that I think has more advantages than other project file structures you’ll see online.
Choosing a Framework
Before we start with anything, we first need to choose which framework library we’re going to use to write our project. You can select the default React framework library but you can also select a faster framework library that has been built on React. Here are two examples you can choose from:
Both are lightweight, powerful, and useful and I suggest choosing one of these two options over the default create-react-app option. For this example, I’m going to use Next.JS with TypeScript.
Creating Our Project
As I said earlier, I’m going to use Next.JS with TypeScript, and in case you don’t know or forgot how to create one, here’s the line of code using NPM.
npx create-next-app@latest --ts
After choosing a name and waiting for a minute, we get a blank Next.JS TypeScript project template.
Our New Folder Structure
src
abstraction
enums
models
types
assets
icons
images
components
constants
hooks
mocks
requests
styles
theme
utils
So this is our new folder structure. As you can see we created around 13–15 different folders that we’re going to use with each one. Now let’s dive into an explanation for each folder.
Of course, outside of src folder there should be other folders such as node_modules and public, and there should be other files such as package.json, .gitignore and tsconfig.json. I won’t talk about these kinds of files and folders in this article.
Abstraction
This is a very unique folder and you won’t see it much in any online tutorial, blogs, videos, etc. It’s a personal preference that I found very useful and helps with navigating through the project much easier.
It contains three different folders:
- enums
- models
- types
The reason we grouped these three folders into one is that we’ve got a lot of similarities between the three and the only difference is the declaration type.
For people that use interfaces instead/with types, you can add in abstraction folder an `interfaces folder too.
Assets
This folder can be placed in different places throughout the project and it depends on which framework you use. For now, I put it inside the src folder as the other folders.
Within these folders, all files that are not scripts and are being used in code should be placed. Examples of these kinds of assets:
- Icons (Preferred to be SVG)
- Images
- Fonts
- Gifs
- Videos (Try to not save videos in project files and store them in the cloud and fetch them on start)
Components
Probably this folder would be the biggest folder in your project over time since you’re going to create more and more components that you’ll use in your project.
It’s important to keep here the components that are being reused through the project or that you think you might use somewhere in the future.
Also, there is a folder structure for a component folder. What I found useful is doing this:
`
component-name
component-name.test.tsx
component-name.tsx
styles.css
The reason the name of the component file and the test file is the same name as the folder is that it’ll be much easier to search for files in your project. If it was just an index file then you’ll have to type component-name/index in order to get that file while you can just type component and you’ll get a reference for the component-name.tsx file much quicker.
If in your component there are other components that are only being used in that component and won’t be used in other components, you can create a components folder inside your component and put those files there.
In case you’re special and you do create test files and actually test your components, you should name the file as your component’s name with a following test or spec word (i.e. component-name.test.tsx). It’ll be much easier to find your file this way.
You can name your styles file however you like but since most of the time you rarely search for a specific component’s style file, I prefer to just name it as styles.tsx.
Constants
Sometimes you have a const value that won’t be changed and is used in different places inside your project or just a large const value that you’d like to save in a separate folder instead of where you’re using it. All these kinds of variables should be inside a constants folder.
Hooks
I really encourage you to create your own custom hooks. A lot of people don’t realize the potential you can get by creating custom hooks. Basically, if you have a couple of components with the same logic, you can just extract that logic into custom hooks and use that hook within those components.
In addition, if you create a custom hook, don’t forget to test it.
Mocks
Sometimes you use mock data instead of real data because you use it in testing, saving requests in development mode or even instead of a route that hasn’t built yet but you know how the data should come. Here you put all your mock files and forget about it.
Requests
Almost in any project, you’ll have to make requests to fetch, create, delete and mutate data. Here you should put all requests you’re going to make to external APIs. In each request file, you should write a simple function that fetches an API request with validation.
Styles
Each component has its own style file but when your project gets bigger and bigger, some components will have common styles. Those kinds of common styles should be extracted from those components and be in a separate file inside src/styles folder.
Theme
Usually, when you use a components design framework library, there is a theme that you can create/edit. This kind of file should be here to get much easier access each time you’d like to edit something in your theme.
Utils
Last and not least — the utils folder. A simple folder that contains repetitive util functions that you use throughout your project. For example, a utils function that converts an image to base64 format should be in utils folder.
So this is my way of organizing my folder structure in my React projects that I find very useful for navigating and saving in the right order.
There is also a lot more stuff that we didn’t talk about such as absolute imports, ESLint, Prettier, Husky, testing, and more. I encourage you to read about these topics too and step up your skills and make your project look and feel so much better.
I hope you find this article useful and that you learn something new that you didn’t know before I’m more than happy to reply to any questions that you have on your mind :)
Top comments (1)
can i get your example project which using this structure files?