Scalable folder structure plays a big role in project maintenance. We need an intuitive folder structure which other developers in the team will find it easy to locate and easy to relate, I call it as ELER.

MVC folder structure sucks

I am not a big fan of MVC folder structure wherein we create Models, Views and Controllers folders and place files respectively. This folder structure has few problems like scalability, as project grows the number of files in each folder also keeps growing hence defeating the purpose of easy to locate. Also if we want to find out files related to a particular module or feature we need to go in each folder and then we have figure out which file belongs to which feature hence defeating the purpose of easy to relate.

Feature/Module folder structure even sucks

I am also not a big fan of having folders created according to the feature or modules, the above MVC folder structure issue can be resolved by this pattern. But the problem statement is that by looking into URL of the browser I should be able to figure out what goes where, which means ELER(Easy to Locate, Easy to Relate). So what if the screen has tons of features in it, we need to navigate to all those feature folders and again we by ourself has to figure out that each page contains what features and we then have to navigate to the folders respectively.

Organizing folders by screens

While the folder structure which I believe is scalable, not only goes well with React, it can go well with any front end application. But since I have been doing React in recent time, I believe it goes really well with it. I have in-fact even used the similar structure while developing a React Native application. Here is the screenshot.

We can look at our URL in browser and can navigate directly to screens folder. Screens folder will have folders which will be the direct mirror of URL. See the below screenshot of expanded version.

The above structure makes it super simple to locate files and looks like the exact mirror of our route URL in browser.

Lets take an example here

Example 1 — https://example.com/events

In this case the navigation to the folder will be Screens --> Events --> index.js

Screens
  |-- Events
    index.js

Example 2 — https://example.com/events/1/details

In this case the navigation to the folder will be Screens --> Events --> Screens --> EventDetails --> index.js

Screens
  |-- Events
    index.js
    |-- Screens
      |-- EvemtDetails
        index.js

Note that Home folder is the default landing page of the website. Lets look into other folders, store folder is related with redux files, we should though only have one store folder in the main screen folder, as having store folder in each sub screen folder will mess things up, shared folder will have those components which will be shared between screens. I like naming screen folder in UpperCamelCase and all other folder names in lowerCamelCase,also I like having index.js as the default entry file into a particular screen folder. We can look into other useful folders like helpers and utils, below you can see the expanded version of these folders(we can see in Screenshot(1) the helpers & utils folder).

In helpers goes all the reusable components which we use throughout the website, one thing to note over here is that I prefixed all the helper files with Application like ApplicationModal. The reason being is we want to differentiate the helpers we created from the third party node modules we installed. Then we have utils folder which has utility libraries, which acts as a particular service serving particular purpose, example being DateServicefor date operations like converting local date to UTC date, handling internationalization, NetworkRequestService for doing network calls like ajax calls, TokenService for token session handling like expiration of token and so on.

Pitfalls

Well not everything is roses with this approach, there are few pitfalls though as described below.

If the routes are too big then we have to create many sub screens folder and navigate to many of these sub screen folders. We can resolve this issue by limiting our cascading of folders to 3 level, beyond 3 level we should maintain all folders at the 3rd level and giving a meaningful name which a user can easily relate to.If the route name changes then we have to create a new folder in screen folder and move the files to that folder, also we have to change the name references used(although this is optional). I still believe that the old folder shouldn’t be removed, What if the user has bookmarked the URL, in this case the old folder should only have index.js file which should redirect user to the new route.The import path in few cases can go weird and difficult to manage like import DateService from ‘../../../../utils/DateService.js’. Although I have seen people resolving this issue using Webpack, never did myself so not sure about this.

Conclusion

All this doesn’t matter much if the project is small to handle and there isn’t much overhead of maintaining it going further. But this all makes sense when project grows and maintaining it becomes a nightmare.

Closing note

Let me know what you think about this folder structure and have any opinions or suggestions on this. In my future articles I am going to talk about the architecture for ReactJS application.

So stay tuned.