Skip to content

Latest commit

 

History

History
91 lines (66 loc) · 5.1 KB

META.md

File metadata and controls

91 lines (66 loc) · 5.1 KB

This md lays out how this project is structured.

Execution

Since it's an electron project, there are two points from where the execution begins.

  1. Main Process: Think of this as the server, the file where this beings is books/main.ts
  2. 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 Structure

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.

Special Folders

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

client*

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.

Special Files

Other than this there are two special types of files:

**/types.ts

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.

**/test/*.spec.ts

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.