- React JS
- Redux Thunk
- Redux Form
- Redux Logger
- Axios
├── 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
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).