React JS Authenatication Folder Structure

react-authentication-folder-structure.md

React JS Authenatication + REST API

Used Packages

• React JS
• Redux Thunk
• Redux Form
• Redux Logger
• Axios

The Project

• https://github.com/mksglu/react-redux-authentication

Folder Structure

├── Dockerfile
├── docker-compose.yml
├── nginx
│   └── conf
│   └── conf.d
│   └── default.conf
└── src
├── applications
│   ├── actions
│   │   └── LoginAction.js
│   ├── constants
│   │   └── AuthConstants.js
│   ├── reducers
│   │   ├── AuthReducer.js
│   │   └── index.js
│   ├── router
│   │   └── PrivateRouter.js
│   └── store
│   └── index.js
├── assets
│   ├── img
│   │   └── logo.svg
│   └── style
│   ├── auth.css
│   └── bootstrap.css
├── containers
│   ├── AppContainer.js
│   └── AuthContainer.js
├── elements
│   ├── Form
│   │   ├── Button.js
│   │   └── Label.js
│   └── ReduxFormFields
│   └── TextField.js
├── helpers
│   ├── api.js
│   ├── history.js
│   └── url.js
├── index.html
├── index.js
└── passenger
├── Auth
│   ├── Login
│   │   ├── LoginForm.js
│   │   ├── LoginFormValidation.js
│   │   └── index.js
│   ├── Logout
│   │   └── index.js
│   ├── Register
│   │   ├── RegisterForm.js
│   │   ├── RegisterFormValidation.js
│   │   └── index.js
│   ├── brand.js
│   ├── footer.js
│   └── index.js
└── Layouts
├── About
│   └── index.js
├── Home
│   └── index.js
└── index.js

• assets
  • img
  • style
• auth
  • AuthContainer
  • AuthConstants
• pages
  • ...
• application
  • store
    • ...
  • reducer
    • ...
  • action
    • ...
• components
  • ...
• utils
  • ...
• route
  • ...

Thanks for doing advice comment. I rearranged the folder structure. But, I have a question. Where should AppContainer be located in this directory structure? @cenkce

└── src
    ├── application
    │   ├── actions
    │   │   └── LoginAction.js
    │   ├── reducers
    │   │   ├── AuthReducer.js
    │   │   └── index.js
    │   └── store
    │       └── index.js
    ├── assest
    │   ├── img
    │   │   └── AuthLogo.svg
    │   └── style
    │       ├── Auth
    │       │   └── Auth.css
    │       └── Bootstrap
    │           └── Bootstrap.css
    ├── auth
    │   ├── AuthConstants.js
    │   └── AuthContainer.js
    ├── components
    │   └── Auth
    │       ├── Brand
    │       │   └── index.js
    │       ├── Footer
    │       │   └── index.js
    │       ├── Pages
    │       │   ├── Login
    │       │   │   ├── index.js
    │       │   │   ├── LoginForm.js
    │       │   │   └── LoginFormValidation.js
    │       │   ├── Logout
    │       │   │   └── index.js
    │       │   └── Register
    │       │       ├── index.js
    │       │       ├── RegisterForm.js
    │       │       └── RegisterFormValidation.js
    │       ├── Particles
    │       │   ├── Form
    │       │   │   ├── Button.js
    │       │   │   └── Label.js
    │       │   └── ReduxFormFields
    │       │       └── TextField.js
    │       └── Route
    │           └── PrivateRouter.js
    ├── containers
    │   └── App
    │       └── index.js
    ├── index.html
    ├── index.js
    ├── pages
    │   ├── About
    │   │   └── index.js
    │   └── Home
    │       └── index.js
    └── utils
        ├── FetchUtils.js
        └── HistoryUtils.js`

• src
  • Global (This part contains only global and reused scripts & components)
    • Components
    • Apis
    • Containers
    • Assets
    • Actions
    • Routes
    • Reducers
    • Sagas
  • Init (This part works for the initialization of the application)
    • Components
    • Containers
    • Workers & Cookie Systems
    • Stores
    • RootSagas
  • Public (Entire public and authentication logic lies here)
    • Components
    • Containers
    • Apis
    • Layouts
    • Assets
    • Actions
    • Routes
    • Reducers
    • Sagas
  • Authenticated Separated Application (Customer Dashboard, Partner Dashboard etc.)
    • Components
    • Containers
    • Apis
    • Layouts
    • Assets
    • Actions
    • Routes
    • Reducers
    • Sagas

We utilize highly separated application structure with different layout operations, which allows us to use a global importing and exporting. We also separate our entire front-end business logic in a different structure which allows us to separate our front-end in 2 different teams (One focuses on UI and UX, the other focuses on front-end based business logic - like a backend -, this area also handles all the caching and storage related contents)

Also for the naming of components, only import-export scripts (like a separate applications reducer or saga) and Global / Init applications can have an index.js file. Currently in the entire project with 5 different Separated Application structure has 10 index.js files.

In a single application level, all containers, components, apis, actions, reducers and sagas have the same folders inside with namings define what the logic is (such as CustomerCreationByPartner, ProcessingListingByCustomerBranch etc.)

This kind of structure requires a little bit of getting used to but when implemented, we figured out it is one of the best approach that we used so far. (Our current local application contains 150k lines along with 100k more in web application, so this kind of structure can be an approach for large codebases).

Auth diye bir component olmaz ki Auth ayri bir modul yada katmandir auth'dan kasit nedir anlayamadim mimari olarak bir soun var sanki.

you could prefer App instead of AppContainer, it is the root of the application and I think it must be in the source code root dir for example src/App.js

Mr. Cenk,

If your comment is related to our structure, we dont have a component for auth logic. Our entire auth logic is lies under another app structure, which overlaps the entrance points of the authenticated separated applications.

---

Cenk bey,

Eğer yorumunuz benim paylaştığım yapıyla alakalıysa, bizim auth için bir component yapımız bulunuyor. Tüm authentication mantığımız ayrı bir app yapısında tutuluyor ve authentication gerektiren tüm alt app yapılarına girişi route seviyesinde kontrol ediyor.

And seperate contexts of a domain must be seperated modules and they never implement each other. You can decide this by looking at size of a module as well. For example in a hospital domain, ER must be seperated module. Because of it's different than clinics or accounts deparments. And they connect each other using events or subdomains.

Ben olsam
Authenticated Separated Application yerine

• DashboardCore
• PartnerDashboard
• CustomerDashboard

diye ayri moduller yapardim. Cunku anck bu sekilde liskov substitution ve open&close uyumlu olur.

Gençler o değilde, react-router'ın amk. Vue'ye gelin.

In a domain, naming convention is one of the most important topics. And unrelated naming can break application architecture.

Mr. Cenk,

Due to our business logic, I couldn't shared all separated applications but they actually are like what you are listed. :)

All our separated structures contains a part of our app (such as ER, Dermatology or Surgery departments of the hospitals).
All governing events and actions that are generating any connections in between these, are lying in another app that is not listed in the structure above, for the sake of simplicity.

Actually, I also love Vue and support it as much as I can. We are using react in our enterprise solutions and web applications because of our teams knowledge on it. We even are not migrating to version 16 and using a react fork that is hosted in our company gitlab for preventing possible future dependency problems.

In the case of our business, we rely on javascript (node + express + electron), type systems and testing probably more than our react part of the codebase :)

No, Dermatology is taxonomy, it's based on the project. If you develop a account management application, it's just a category. But if develop a R&D application it can be a context. If you divide a hospital as Clinics, ER, Account etc. and then it's just a part of taxonomy of the clinics but some clinics have big differences than others, they can be context. It's related with project needs.

Ahahahah, my knowledge on hospitals are becoming short on this topic currently.

What I was trying to tell is, the folder structure that I have posted are currently the best structure that our team is used in the last 1 year. Using codebases with 150k + 130k (approximate numbers based on our previous releases on local, frontend and backend applications), a structure like that is helping on the development and security layers in quite a good way :)

Also, I cannot give thumbs up to your comments but all of them should get one :)

I don't know what your project needs, I just try to create a case study to discuss that what project structure is. I don't want to misunderstand. Actually as you said, the point is what project needs. For example our modules of the project seperately run and they don't exactly know each other. Each module can easily run by just using its own code base like micro-services.