... | ... | @@ -12,16 +12,12 @@ |
|
|
|
|
|
> 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.
|
|
|
|
|
|
-
|
|
|
- **'state-component-based' architecture**
|
|
|
|
|
|
Stage management in the application (no state/data stored in the DOM).
|
|
|
|
|
|
Components
|
|
|
Views observe model changes (event system), reflect the content of the models. Views implementation based in uncoupled UI components using a programmatic approach (internal templating).
|
|
|
Distinguish **definition code from initialization code**. Reusable components should be defined without actually being instantiated/activated.
|
|
|
|
|
|
* **unidirectional data flow**:
|
|
|
flow-based programming, where data flows through the application in a single direction — there are no two-way bindings.
|
|
|
|
|
|
----
|
|
|
|
... | ... | |