Skip to content
This repository has been archived by the owner on Nov 6, 2020. It is now read-only.

Project Structure

Jump to bottom
Norman Fomferra edited this page Nov 24, 2016 · 3 revisions

This page describes how the source tree of cate-desktop is organised.

High-Level Source Tree Structure

cate-desktop/
├─ src/                   
|   ├─ common/                 
.   ├─ desktop/                
.   ├─ web-desktop/            
.   └─ web/

The common Module

Code in src/common can be used in all other modules. No API is allowed besides plain JavaScript API.

The desktop Module

Code in src/desktop runs in Electron's main process. The allowed APIs are the Electron API and Node API.

The web-desktop Module

Code in src/web-desktop runs in Electron's renderer process, but must communicate with Electron's main process. It is used to delegate events coming from Electron's main process to code in web. The allowed APIs are the allowed APIs for the web module plus the Electron Remote API.

The web Module

src/web contains code that runs in Electron's renderer process (Chromium) and later on in any other browser (Firefox, Safari, Edge). The allowed APIs are Web API, React API, and Redux API. The structure is as follows:

src/web/
 ├─ common/        
 ├─ feature-1/     
 ├─ feature-2/      
 ├─ .../           
 └─ feature-N/      
    ├─ index.ts
    ├─ reducers/     
    ├─ actions/      
    ├─ stores/       
    └─ components/ 
       ├─ comp-1/
       ├─ comp-2/
       ├─ .../
       └─ comp-M/      
          ├─ index.ts
          ├─ icon.png     
          ├─ style.css     
          ├─ FeatureNCompM.tsx     
          └─ .../

Justification

There are many ways to structure React/Redux based applications. We decided to structure the source tree according to features rather than type. To explain the difference, here is a source tree structured by type as suggested by many React developers:

.../
├─ components/
├─ containers/
├─ actions/
├─ stores/
├─ reducers/
├─ ...

And here is one structured by feature:

.../
├─ operation/
├─ dataset/
├─ workspace/
├─ layer/
├─ analysis/
├─ ...

The advantages of a feature-oriented structure are as follows:

  • A feature can be easily identified as an independent, pluggable module. While implementing a new feature, developers stay in "their" sub-directory.
  • Software usually grows because new features are added. In a type-oriented structure, new features will contribute to all sub_directories, which makes it hard to keep things together and to view them as one unit.
  • In a type-oriented structure we would have all components in a components folder. This makes it hard to trace each components usage and its dependencies in the code and also where it will finally appear in the UI.
  • A feature-oriented structure can still have a type-oriented sub-structure, for which we can define the allowed and forbidden dependencies.

The project structure described here is based on the ideas provided in the article How to better organize your React applications?.

Clone this wiki locally