Skip to content

Instantly share code, notes, and snippets.

Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save casamia918/135707cc2c69042a54cfc5d17280dd30 to your computer and use it in GitHub Desktop.
Save casamia918/135707cc2c69042a54cfc5d17280dd30 to your computer and use it in GitHub Desktop.

https://reactjs.org/docs/faq-structure.html#avoid-too-much-nesting

When you're working on react project, you may concern that which directory structure is better between group by features and group by types. (see above react document)

Recently, I've developed two different types of project. And here I leave a note to give advice from my experience.

In these days, there are two type of react applications.

One is organized by pages, which looks like ordinary website, move pages by routing mechanism. The other one has only one page but have many features in the single page. For example, you can think of Web editor (jsfiddle), Web chat, and so on.

After I finished both projects (actually, one is on working), I concluded myself.

Multipage application, which looks like normal websites, is well fitted to "group by feature" directory structure. On the other hands, Single page application (in this context, I discriminate from technical terminology “single page application”. be aware of it.) is well fitted to “group by types” directory structure.

Let me give you more detailed explanation.

When organize application directory structure, the most important things to consider are

  1. hierarchy 2. reusuability.

Actually, if you are not an insane developer, you should have no problem at file hierarchy. As the file have more concrete and detailed content, it will be located in the deep directory.

Meanwhile, when you encountered that some codes are shared by multiple files, you may consider to modularize that code by pulling out the codes into single file and import it in the multiple files. This is the reusuability.

In react project, there are some standard kind of files that many project have commonly used.

  • component (reusuable react components)
  • page (componant for page in multi page application)
  • libs (project opinioned code)
  • config
  • model (usually classes for view logic)
  • state (store in mobx, reducer in redux, context, and so on. )
  • api
  • hook (if you use functional component)
  • app (application root component)

from above, our main concerns are component, page, model, api, state.

In single page application, surely, page is not a big thing. But you have many small components that is highly dependented to the model, api, and state logic. So, in this case, locate same types of files into same directory is much clear and easy to use, obviously.

But in multipage application, things are quite different. When you create some model or state logic for page, it will be highly reused in the specific page or specific page group. So group by feature (in many case, boundary of feature will be equal to page) is much adequate. Put components, model, state logic, api in the same directory.

But, in contrast with single page app, multipage application may have commonly used files that multiple page shares. So, it would be nice to consider top-level directory which contains same kind of files. I know this is exceptional case and not good for our directory structure, but it cann’t be avoidable.

In my case, multipage app project files can be structured by below named directories.

  • components(atomic react components)
  • scene(navigation scene(page) components. but as the “page” is so valuable and can be used in the various situations, let’s use more unique and superior word, scene. Now, scene components, model, store, scene specific codes can be gathered in the specific scene directory. This is main purpose to use this directory structure. It’s very nice. )
  • entity (some top level business files, such as user, product. If multiple scene shares same models frequently, consider it to locate in entity folder)
  • base(all kind of base classes. such as api, model, store. )
  • services (the communication interface between app and outer environment. commonly, api, device, push, sns, etc)
  • modules (commonly used components in the entire app. such as navigation, alert, header bar, tab bar, sidemenu. In atomic design, these components can be treated with organism or template. But as these components are special to app, I think pull out these components and put in top level directory is more wise to use. you have to admint that somethings are special and should be treated as well. )
  • libs, config, app are same with single page app.

That’s all! At first, you may be uncomfortable by seeing many top level directories. But as project bigger and bigger, you will be understand why I suggest above structures.

Good luck!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment