Modules Folder Structure

Introduction

As a reference, this section contains the documentation about folder structure and file name conventions of modules.

Folder structure

To ease understanding, below we have a folder structure example of the mobilization/blocks module. This structure is ideal for creating new modules, but it is not strictly mandatory for it to be followed. But to ease understanding of the code and better maintainability, we suggest that the modules have a similar folder structure.

/app
└── /modules
    ├── /accounts ------------------------- module
    ├── /communities ---------------------- module
    ├── /mobilizations -------------------- module
    │   └── /blocks ----------------------- submodule (example target)
    │       ├── /action-creators
    │       │   ├── create-action.js
    │       │   ├── create-block.js
    │       │   ├── destroy-block.js
    │       │   ├── load-blocks.js
    │       │   └── update-block.js
    │       ├── action-types.js
    │       ├── /components
    │       │   ├── block-miniatures.js
    │       │   ├── block-widgets.js
    │       │   ├── block.js
    │       │   └── index.js
    │       ├── /containers
    │       │   ├── block-container.js
    │       │   └── index.js
    │       ├── /pages
    │       │   ├── index.js
    │       │   └── new-block-page.js
    │       ├── paths.js
    │       ├── reducers.js
    │       └── routes.js
    └── /widgets

Max depth

To avoid infinite nesting of the modules and their respective submodules, we suggest that the max depth value of the nested modules must be 1 to keep structure most flat as possible. e.g.

modules
├── accounts --------------------- depth: 0
├── communities ------------------ depth: 0
├── mobilizations ---------------- depth: 0
│   ├── blocks ------------------- depth: 1
│   └── widgets ------------------ depth: 1
└── widgets ---------------------- depth: 0

Module structure

Action creators

blocks
└── action-creators

In this directory we include all the actions related to our module. Such as async-block-create, async-block-load, etc...

Components

blocks
└── components

Here we include all components related to our module. Those components must be pure and if it needs state manipulation, the dispatch of redux must be injected via prop.

Containers

blocks
└── containers

Here we include all containers related to our module. Containers are Higher Order Components (HOC) responsible for fetching the data that will be injected into the child components (blocks/components). In the future releases, this pattern will be removed replacing this behaviour by redial.

Pages

blocks
└── pages

Here we include all pages related to our module. Pages are components that "wraps" pure components. In most cases pages are components that handle the state via redux. Each page must have a route path.

Paths

blocks
└── paths.js

Here we include all paths related to our module. Paths are the route path that pages are accessed via react-router.

Reducers

blocks
└── reducers.js

Here we include all reducers related to our module. Reducers are the way that redux manipulates the state. Reducers are accessed via actions. More informations about reducers here.

Routes

blocks
└── routes.js

Here we include all routes related to our module. Routes are react-router router components that makes pages accessible via url.