@sayduck/viewer-jellyfish v0.2.12-1

sayduck-viewer-jellyfish 🦆

In this repo lives the new iteration of Sayduck's commercial 3D Viewer.

Table of Contents

1. Usage

Our mission

This iteration of our 3D viewer fixes the pitfalls of sayduck-viewer-threejs:

• Inter-dependency across multiple repos for our frontend code
• Delayed display of 3D due to used design pattern
• Heavy bundle size
• Lack of loading priority
• Lack of tests / cd / ci and defined processes
• Difficulty for developers to onboard due to excessive complexity

Main goals:

• Code Splitting
• Modularity
• Speed and Maintainability

Github flow and organisation

Branches

• main - production
• development - staging

Prefixes

• feature/ - for features (directly tied to an issue)
• bug/ - for bugs (directly tied to issue)
• doc/ - for documentation, comments, etc
• chore/ - pkg bump, test regression etc

Logs

• BRANCHLOG - Current changes for a named branch.
• CHANGELOG - Current changes for development branch

Code organisation

### Module based development

In an effort to reduce files size and improve readability we decided to isolate code by concerns and group each concern in its own module.

By using this method coupled with webpack we reduce the initial downloaded bundle size by only loading the necessary modules to the bootstrap of our 3D viewer. The rest of the modules are loaded on a need basis at runtime.

FIXME: add a tree dependency of the modules before release

Basic rules to follow

1. Global

   1. Add comments only if they bring value and explain the business logic

   2. Avoid multiple purpose classes

   3. Create service classes to group shareable logic

   4. List first the attributes then the methods when writting a class

   5. List them in the order: public, protected, private

   6. add //#region private methods and //#endregion to protected and private methods

   7. When creating an empty folder use an empty .keep file

   8. When adding a file to an empty file remove the .keep file

2. Modules

   1. Module should lay in /src/modules/${name}-module/${name}-module.ts

   2. Modules' name needs to be referenced in lowercase in the MODULE_NAME

   3. Default prototype should be default export class Foo extends Module {}

   4. See Module for abstract methods and attributes to implement in a new module

3. Types

   1. Types used for constant values should be spelled in capital letters

   2. Don't save types inside other classes files, save them in their own file

4. Tests

   1. Create the spec file in the same folder than the class

   2. Create a temporary spec file from the get go

   3. Add a test.todo() to not forget it later and to flag it on deploy

   4. Describe your tests file with the class you are testing.

      Example for example for the class App: app.spec.ts

      import type App from './app';
      
      describe(App, () => {
          test.todo('');
      });

Linting

We use eslint with a slightly modified version of very popular Airbnb JavaScript Style Guide coupled with our prettier

Testing

All our functional testing is done with jest. To run the tests simply execute npm test