How to Structure a React Project

[00:00 - 00:15] Lesson 3 - React Project Structure There is a good not perfect axiom that I think is key when thinking about project structure. Again, it's a weirdly overly thought about subject, but you'd be surprised how difficult it can be to be presented with a complete blank canvas and ask to start adding files and folders to it.

[00:16 - 00:32] In this lesson, we'll take a look at some of the common approaches to structure and your React projects. First up, React own based project structure. We've created a number of projects using the Create React app tool so far, so let's start by looking at a brand new Create React app project structure and go from there.

[00:33 - 01:00] You can see that it's quite flat by design. There's no complex nesting structure and indeed the React team advises against nesting more than three levels deep. React, being so un-opinionated, and understandably provides a really un-opinionated project structure with its Create React app project. However, rather than looking at it from a "we don't want to push any wares of doing it on your angle", I prefer to think about it as a great starting point that gives you just enough structure to get you going without adding in complexity or pushing you down a set route from the start.

[01:01 - 01:18] Let's take a look at my common structure. I like to start with this clean approach that's quite flat and then have a number of different top-level folders to suit different areas of responsibility. So in components, this houses all of the smaller components and presentational ones. I might add additional folders that group some related components together such as farm fields.

[01:19 - 02:22] In the Containers folder, because I like the split between presentation and logic, I put my management components that look after logic and data handling, I keep them in the Containers folder. In the Lib folder, anything that's functional but not directly react related, such as data handlers, API fetches, or utility files get put in here. If I'm using Redux, I like to keep my Reduces and Action Creators in a Reduces folder. With Layout, although still holding components, for more complex layouts within apps I find it helpful to have a dedicated layout folder for these more structural UI components. In data, this usually holds any static data, such as initial state or JSON files, and with assets, this folder houses CSS files, SCSS files, images, or other similar asset files. Some of these might not be relevant, depending on the type of app or site I'm building. We do have some other popular options to look at too, so let's talk about those. The first one, grouping by features are roles. One popular way of structuring your React projects is to group your components and files by their features or routes.

[02:23 - 03:29] Consider the following mock structure. So here we have a common folder that houses a number of common or global files that we shared across the app. Then we have a feed folder that houses everything related to the feed feature. Similarly, we have a profile folder that deals with everything to do with the user's profile. This is quite a neat approach and makes for easy maintenance and finding of files. You'll notice that we have a mixture of file types in there, including CSS files and .js functions, an API caller, and the main index.js entry point for that route or feature. This approach will be more helpful in larger, more complex projects, but possibly overkill for smaller apps and sites. The second type, grouping by file type. The grouping by file type approach is a little more like the one I prefer that I mentioned at the beginning. In practice, it might look like this. You can see that we have a dedicated API folder that holds everything API related. And then we have a components folder that holds both the component itself and associated CSS file. This is a much flatter structure that lends itself well to the type of files in your project. It could grow a little unwieldy if your project grows quite large or more complex.

[03:30 - 04:08] A final thought on project structuring. I know a lot of people may include like to overthink these things. During my career, I've even had meetings where I've spent over an hour in a meeting discussing folder structure on a project. One to two hours in a meeting with 10 other engineers is close to two full days of lost development time. And guess what? Even if you agree on a structure ahead of time, code projects and software are like living organisms. They change over time, adapt to changes, news and needs, available technologies and preferences, or best practices. So my advice is the same as the official React advice from their documentation website. Don't overthink it. Don't spend more than five to ten minutes deciding on a folder structure.

[04:09 - 04:11] You can always change things as you go and refactor it as you need.