This md
lays out how this project is structured.
Since it's an electron project, there are two points from where the execution begins.
- Main Process: Think of this as the server, the file where this beings
is
books/main.ts
- Renderer Process: Think of this as the client, the file where this
begins is
books/src/main.js
Note: For more insight into how electron execution is structured check out electron's Process Model.
This process is architected in a client-server manner. If the client side
requires resources from the server side, it does so by making use of
ipcRenderer.send
or ipcRenderer.invoke
i.e. if the front end is being run on
electron.
The ipcRenderer
calls are done only in fyo/demux/*.ts
files. I.e. these
are the only files on the client side that are aware of the platform the
client is being run on i.e. electron
or Browser. So all platform specific
calls should go through these demux files.
Code is structured in a way so as to maintain clear separation between what each set of files structured under some subdirectory does. It is also to maintain a clear separation between the client and the server.
The client code should not be calling server code directly (i.e. by importing it) and vice-versa. This is to maintain the client code in a platform agnostic manner.
Some of the code is side agnostic, i.e. can be called from the client or the
server. Only code that doesn't have platform specific calls example using
node
fs
or the browsers window
. Ideally this code won't have an imports.
Here's a list of subdirectories and their purposes, for more details on
individual ones, check the README.md
in those subdirectories:
Folder | Side | Description |
---|---|---|
main |
server | Electron main process specific code called from books/main.ts |
schemas |
server | Collection of database schemas in a json format and the code to combine them |
backend |
server | Database management and CRUD calls |
scripts |
server | Code that is not called when the project is running, but separately to run some task for instance to generate translations |
build |
server | Build specific files not used unless building the project |
translations |
server | Collection of csv files containing translations |
src |
client | Code that mainly deals with the view layer (all .vue are stored here) |
reports |
client* | Collection of logic code and view layer config files for displaying reports. |
models |
client* | Collection of Model.ts files that manage the data and some business logic on the client side. |
fyo |
client* | Code for the underlying library that manages the client side |
utils |
agnostic | Collection of code used by either sides. |
dummy |
agnostic | Code used to generate dummy data for testing or demo purposes |
The code in these folders is called during runtime from the client
side but since they contain business logic, they are tested using mocha
on the
server side. This is a bit stupid and so will be fixed later.
Due to this, the code in these files should not be calling client side code
directly. If client side code is to be called, it should be done so only by
using dynamic imports, i.e. await import('...')
along pathways that won't run
in a test.
Other than this there are two special types of files:
These contains all the type information, these files are side agnostic and should only import code from other type files.
The type information contained depends on the folder it is under i.e. where the code associated with the types is written.
If trying to understand the code in this project I'd suggest not ignoring these.
These contain tests, as of now all tests run on the server side using mocha
.
The tests files are located in **/test
folders which are nested under the
directories of what they are testing. No code from these files is called during
runtime.