ref(electron): define project source code directory structure

[aesedepece]

As we start to devote more efforts to the front end side of Sheikah, our project source code will naturally tend to break separation of concerns unless a directory structure policy is defined and enforced ASAP.

Being one of the most popular Electron powered projects, behold Atom for reference:

Electron
  ├── atom/ - C++ source code.
  |   ├── app/ - System entry code.
  |   ├── browser/ - The frontend including the main window, UI, and all of the
  |   |   main process things. This talks to the renderer to manage web pages.
  |   |   ├── ui/ - Implementation of UI stuff for different platforms.
  |   |   |   ├── cocoa/ - Cocoa specific source code.
  |   |   |   ├── win/ - Windows GUI specific source code.
  |   |   |   └── x/ - X11 specific source code.
  |   |   ├── api/ - The implementation of the main process APIs.
  |   |   ├── net/ - Network related code.
  |   |   ├── mac/ - Mac specific Objective-C source code.
  |   |   └── resources/ - Icons, platform-dependent files, etc.
  |   ├── renderer/ - Code that runs in renderer process.
  |   |   └── api/ - The implementation of renderer process APIs.
  |   └── common/ - Code that used by both the main and renderer processes,
  |       including some utility functions and code to integrate node's message
  |       loop into Chromium's message loop.
  |       └── api/ - The implementation of common APIs, and foundations of
  |           Electron's built-in modules.
  ├── brightray/ - Thin shim over libcc that makes it easier to use.
  ├── chromium_src/ - Source code copied from Chromium. See below.
  ├── default_app/ - The default page to show when Electron is started without
  |   providing an app.
  ├── docs/ - Documentations.
  ├── lib/ - JavaScript source code.
  |   ├── browser/ - Javascript main process initialization code.
  |   |   └── api/ - Javascript API implementation.
  |   ├── common/ - JavaScript used by both the main and renderer processes
  |   |   └── api/ - Javascript API implementation.
  |   └── renderer/ - Javascript renderer process initialization code.
  |       └── api/ - Javascript API implementation.
  ├── spec/ - Automatic tests.
  ├── electron.gyp - Building rules of Electron.
  └── common.gypi - Compiler specific settings and building rules for other
      components like `node` and `breakpad`.

Ok, that's a overly complicated when compared to our modest structure, but I think it brings some good ideas.

As you can see, the lib directory is divided into browser (code run in the main process), renderer (code run by the renderer process) and common (shared code). Both renderer and common target "browser JS", while code browser is NodeJS-specific.

This could be our structure for the time being:

Sheikah
  ├── app
  |   ├── actions
  |   ├── components
  |   ├── containers
  |   ├── lib
  |   |   ├── common
  |   |   |   └── api
  |   |   ├── main
  |   |   |   ├── api
  |   |   |   ├── crypto
  |   |   |   ├── encoding
  |   |   |   ├── storage
  |   |   |   └── utils
  |   |   ├── renderer
  |   |   |   └── api
  |   ├── reducers
  |   └── store
  ├── config
  ├── docs
  ├── resources
  ├── tests
  └── typings

We should give a look to some other projects with similar stacks. Counterproposals are expected 😛

[aesedepece]

@witnet/devs comments?

[anler]

This is my proposition:

sheikah
  ├── app
  │   ├── common              Code shared across main and renderer
  │   ├── main                Main process "the backend"
  │   │   ├── api
  │   │   ├── crypto          Do not use lib/ here, just move
  │   │   ├── encoding        its content under main/. These act also
  │   │   ├── storage         as adapters between our logic and lib/
  │   │   └── ...
  │   └── renderer            Rendering process "the fronted"
  │       ├── api
  │       ├── crypto          Do not use a lib/ here, just move
  │       ├── encoding        its content under main/. These act also
  │       ├── net             as adapters between our logic and lib/
  │       ├── ...
  │       └── ui              The UI itself, redux, react, etc
  │           ├── actions
  │           ├── components
  │           ├── containers
  │           ├── reducers
  │           └── store
  ├── config
  ├── docs
  ├── lib                      Custom libraries that has no dependencies
  │   ├── crypto               to our bussiness logic. Code here has the
  │   ├── encoding             potential to be moved into their own
  │   ├── storage              npm package and distributed separately and
  │   └── ...                  ideally work in both browser and node
  ├── resources
  │   ├── common               Common resources
  │   ├── main                 Resources for the main process
  │   └── renderer             Resources for the renderer process
  ├── tests
  └── typings

[aesedepece]

@anler I like it.

Only objections are store, reducers and actions. These are Redux folders that will contain code defining the app state data model, mutation logic and API, respectively.

I'd take store out of ui and put actions and reducers inside store itself.

About the requirement for the code in lib to be enviroment-agnostic, I agree with you. Of course that means more WebPack configuration in order to polyfill Buffer and many other NodeJS sugary features.

[anler]

Only objections are store, reducers and actions. These are Redux folders that will contain code defining the app state data model, mutation logic and API, respectively.

I'd take store out of ui and put actions and reducers inside store itself.

@aesedepece that sounds perfect

About the requirement for the code in lib to be enviroment-agnostic, I agree with you. Of course that means more WebPack configuration in order to polyfill Buffer and many other NodeJS sugary features.

We can always start by writing those inside app/main or app/renderer (tied to a specific environment) and move them into lib/ later when we need them to be environment-agnostic.

[aesedepece]

#144 is the implementation follow-up of this issue.

[mmartinbar]

I'm integrating the work on #27 into the new project structure and I wanted to get your opinion on this proposal for the IPC methods and handlers:

app
├── common
│   ├── messages.ts
│   └── methods.ts
├── main
│   ├── api
│   │   ├── handlers
│   │   │   ├── index.ts
│   │   │   ├── nop.ts
│   │   │   └── ping.ts
│   │   └── lib
│   │       ├── electronIpcMain.ts
│   │       ├── genericIpcMain.ts
│   │       └── ipcBackend.ts
│   ├── chain
│   ├── ...
├── main.electron.ts
└── renderer
    ├── actions
    ├── api
    │   └── lib
    │       ├── electronIpcRenderer.ts
    │       ├── genericIpcRenderer.ts
    │       ├── ipcFrontend.ts
    │       └── mockedIpcRenderer.ts
    ├── components
    ├── containers
    ├── ...
    
test
├── app
│   ├── common
│   │   ├── messagesFixtures.ts
│   │   ├── messages.spec.ts
│   │   ├── methodsFixtures.ts
│   │   └── methods.spec.ts
│   ├── main
│   └── renderer
│       ├── api
│       │   └── lib
│       │       └── ipcFrontend.spec.ts
│       ├── components
│       ├── containers
│       └── reducers
├── e2e
├── ...

What do you think, @aesedepece, @anler, @witnet/devs?

[anler]

@mmartinbar looks 👌 but here are a couple of suggestions based in my personal taste:

• I would rename app/main/api/lib to app/main/api/ipc and remove IpcMain from the names inside it
• same thing for app/renderer/api/lib

😬