Project Structure

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

cate-desktop/
├─ src/                   
|   ├─ common/                 # Code shared by desktop and web
.   ├─ desktop/                # Code that runs in Electron's main process. Allowed APIs: Electron, NodeJS
.   └─ web/                    # Code that runs Chromium (or any Web-Browser): Allowed
.       ├─ common/        
        ├─ feature-1/     
        ├─ feature-2/      
        ├─ .../           
        └─ feature-3/      
           ├─ components/  
           ├─ reducers/     
           ├─ actions/      
           ├─ stores/       
           └─ index.ts      

Notes:

• src/common: Code that can be used in both desktop and web. No API allowed besides JavaScript API.
• src/desktop: Code that runs in Electron's main process. Allowed: Electron API, Node API
• src/web: 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, Redux API.
• src/web-desktop: Code that 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 all src/web APIs plus Electron Remote API.

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?.