CODEWITHSUNDEEP
reactjsdirectoryredux
ralzaul
ralzaul

Reputation: 4470

Component based React-Redux project directory structure

I know that there are few questions about the react-redux project code structure but I am hoping to discuss a different approach. So the main libraries we are going to use are : webpack - react - redux -mocha - karma.

The classic folder structure for this seems to be: 

js
├── actions
│   ├── action-for-componentA.js
├── components
│   ├── componentA.js
├── reducers
│   ├── reducer-for-componentA.js
└── stores ...

This seems to be what everyone else and all the generators out there are doing. But I feel like this is not the react way of structuring a project. The focus should be on the component and not on the individual constructs of react or redux. I would like to think about it in this way, when you need to change a button in PageX which is contained in a component hierarchy that starts with ComponentX -> ChildOfX - I should be able to traverse the directories in this exact same way.

Rather than having a components folder with all components thrown inside it I would rather have something like : 

js
├── PageX
│   ├── action-for-pagex.js
    ├── componentX.js
    ├── containerX.js
    ├── reducerX.js
    ├── children
        ├── childrenC
        ├── childrenB 
            ├── componentB.js
            ├── reducerB.js
            ├── ...
├── PageY
│   ├── ...
├── PAgeZ
│   ├── ...

This will be easier to traverse and it makes more sense when you think in "react". Can anyone see anything that might go wrong with this approach?

Related reading : http://engineering.kapost.com/2016/01/organizing-large-react-applications/

Upvotes: 4

Views: 1546

Answers (2)

antsav
antsav

Reputation: 255

I've came up with this structure and it works pretty well The folder structure

Upvotes: 1

vorillaz
vorillaz

Reputation: 6276

TL;DR There is no standard or proper way structuring your application's code; it's mostly about your taste.

I will give you an answer due to my experience with React and Redux. Right now, I am involved in a huge project using the R&R stack. Our tech team had spent a great amount of time talking about folder structure since we should keep a linear and scalable way of coding.

Basically, we are using hybrid approach mixing the two examples your have provided. The second approach is referenced as "Folder structure by feature", the first one is called "Folder structure by type".

Since the React/Redux stack uses a standardised typeset of files it's quite easy to keep your application tree as tidy and scalable as possible.

Our technical team has agreed that:

  • Each Main Component stands out under the pages folder.
  • Each page may have some sub components as well.
  • Components are using a component.js entry point and may use a reducer as well
  • Sub components that are actually inherited and used from more than one parent components are placed under the shared folder
  • We also maintain some helper functions folder and a folder that holds some constants and utilities. This is mostly because our action dispatchers use common actions in our application lifecycle.
  • The application is bootstrap by a single container, a single store and simple entry point (app.js).
  • We use ES6 import statements to hold everything in place.

Here is a schematic version of our file structure:

constants
  -- const.js
  -- const2.js
helpers
  --helperfunc1.js
shared
  --Shared Element1
    --- component.js
    --- reducer.js
  --Shared Element2
    --- component.js
    --- reducer.js
specs
  -- spec1.js
  -- spec2.js
pages
 -Page1
 -- Subpage1
   --- component.js
   --- reducer.js
   -- Subpage2
     --- component.js
     --- reducer.js
  -- component.js
 -- reducer.js
 -Page2
 -- component.js
 -- reducer.js
 ...
container.js
app.js
reducer.js

As we kept coding, adding features and maintaining our application, we wrote down some pros of this approach: - Filenames are pretty short and easy to read. - The file structure is easy to follow. - Testing has made damn simple as importing the component and the reducer from a folder - Naming bottlenecks have been thrown away. - We had less naming issues and under the same folder. - Once more, TableDataComponent.js is more verbose and hard to follow than table/component.js. - Since React nested components are an essential part of the framework, the folder structure tracks down this logic. Inner levels of code are inherited from the upper rendered elements. - Action reducers are also smoothly bootstrapped .

I would suggest spending some time reading this wonderful Reddit thread and this article as well, some awesome points are mentioned above.

Upvotes: 2

Related Questions