|
|
### Overview of the client architecture and technical decisions
|
|
|
|
|
|
- The application client part is a typical **Single Page Application**: the client application is loaded at the beginning and the data get changed and updated dynamically at run time from the server. The server has no UI logic nor maintains UI state.
|
|
|
- The application client part is a typical **Single Page Application**: the client application is loaded at the beginning and the data get updated dynamically at run time retrieved from the server. The server has no UI logic nor maintains UI state.
|
|
|
|
|
|
- The application is **strongly graphics oriented** so it makes use of the *Three.js* library. On the other hand it's not using a typical UI global app framework. Instead good patterns and practices are adapted to the project needs.
|
|
|
- The application is **strongly graphics oriented** and it makes use of the *Three.js* library. On the other hand it's not using a typical UI global app framework. Instead good patterns and practices are adapted to the project needs.
|
|
|
|
|
|
- The *module pattern* is the first level of code organization: the application to split into multiple files (*modules*). A module usually contains a class or a library of useful functions. Using the language-level module system (*ECMAScript 6*).
|
|
|
- The **module pattern** is the first level of code organization: the application is split into multiple files (*modules*). A module usually contains a class or a library of useful functions. Using the language-level module system (*ECMAScript 6*).
|
|
|
|
|
|
- **App layout/Code organization**
|
|
|
- **App layout/Code organization** (PENDING)
|
|
|
|
|
|
- Use of **application modules** to organize and get uncoupled and maintainable code. Try to create subsystems (activity implementation) that are not interdependent. Use of **global event system**. Implement a system for inter-module communications based in events to reduce the coupling (pub/sub pattern).
|
|
|
- The concept of **application modules** are used to organize and split the application in big functional parts and have them uncoupled (every application module is formed of more coupled resources). Try to create subsystems that are not interdependent. Use of a **global event system** for inter-module communications based in events to reduce the coupling (*pub/sub pattern*?).
|
|
|
|
|
|
> It's worthy to distinguish file modules (as referred by the above module pattern) from app modules. These use to be composed of lot of file modules (forming a package) and implement a well defined functionality (app activity).
|
|
|
|
|
|
- The application architecture follows the pattern commonly called **Unidirectional architecture**. That is, the addition of composable UI components, application state management and unidirectional data flow.
|
|
|
* **UI components**: Views implementation based in uncoupled UI components using a programmatic approach (internal templating). Views + UI State + User Event Handling. Distinguish **definition code from initialization code**. Reusable components should be defined without actually being instantiated/activated.
|
|
|
* **Application state** management: managing Application State and Business Logic. Application state is maintained only in the stores, allowing the different parts of the application to remain highly decoupled. Stores contain the application state and logic.
|
|
|
|
|
|
* **unidirectional data flow**:
|
|
|
flow-based programming, where data flows through the application in a single direction — there are no two-way bindings.
|
|
|
* **UI components**: Uncoupled views made of a hierarchy of UI elements using a programmatic approach (internal templating). UI component: View + UI State + User Event Handling. Distinguish definition code from initialization code. Reusable components should be defined without actually being instantiated/activated.
|
|
|
|
|
|
* **Application state** management: In this architecture the *store(s)/state* entity is the one in charge of managing the application state and the business logic allowing the different parts of the application to remain highly decoupled. The rest of the application only can change the state by emitting *actions* on the store. The UI components will be notified of a relevant state change if they were subscribed to this kind of change previously.
|
|
|
|
|
|
* **Unidirectional data flow**: The data (events) flow (action -> store -> UI components -> action -> ...) goes through the application in a single direction (*flow-based programming*) — this pattern avoids two-way bindings.
|
|
|
|
|
|
|
|
|
REFERENCES:
|
|
|
[Flux - In Depth Overview](https://facebook.github.io/flux/docs/in-depth-overview.html)
|
|
|
[Redux - Three principles](https://redux.js.org/introduction/three-principles)
|
|
|
[Unidirectional User Interface Architectures - André Staltz](https://staltz.com/unidirectional-user-interface-architectures.html)
|
|
|
[Is Model-View-Controller dead on the front end? - Alex Moldovan](https://medium.freecodecamp.org/is-mvc-dead-for-the-frontend-35b4d1fe39ec)
|
|
|
|
|
|
|
|
|
----
|
|
|
|
... | ... | |