arcane/application_architecture_using_arcane
1
0
Fork 0
mirror of https://github.com/hanskokx/application_architecture_using_arcane.git synced 2026-05-14 10:29:05 +02:00
Code Issues Packages Projects Releases Wiki Activity

Update captions

Browse Source 
Signed-off-by: Hans Kokx <hans.d.kokx@gmail.com>
This commit is contained in:
Hans Kokx
2025-01-10 16:38:20 +01:00
parent 85443a40d8
commit 4ad744a68e
1 changed files with 6 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+6 -2
View File
@@ -89,7 +89,7 @@ A **feature** _generally_ consists of the following components:
> [!WARNING] > [!WARNING]
> No feature should communicate with or depend upon any other feature directly. Inter-feature communication should only occur via services. > No feature should communicate with or depend upon any other feature directly. Inter-feature communication should only occur via services.
Therefore, a **feature** can generally be defined as: Therefore, a **feature** can generally be described in Figure 3.
```mermaid ```mermaid
classDiagram classDiagram
@@ -127,7 +127,9 @@ classDiagram
StateManager *-- API StateManager *-- API
``` ```
As a user performs actions in the UI, events will be sent to the [state management](#state-management). When the state manager receives an event, it may emit a `Waiting` state, causing the UI to rebuild and indicate that the action is currently being performed. Then, the state manager will make a call to the feature's [API](#feature-api) to fulfill the request. Once the API has completed the request, either successfully or unsuccessfully, response is then returned to the state manager for further processing. A new state will be emitted from the state manager to indicate a success or failure state, and again the UI will rebuild to indicate the result. This process can be visualized in the following manner: > Figure 3: The logical representation of a typical feature
As a user performs actions in the UI, events will be sent to the [state management](#state-management). When the state manager receives an event, it may emit a `Waiting` state, causing the UI to rebuild and indicate that the action is currently being performed. Then, the state manager will make a call to the feature's [API](#feature-api) to fulfill the request. Once the API has completed the request, either successfully or unsuccessfully, response is then returned to the state manager for further processing. A new state will be emitted from the state manager to indicate a success or failure state, and again the UI will rebuild to indicate the result. This process can be visualized in the following in Figure 4.
```mermaid ```mermaid
%% SequenceDiagram %% SequenceDiagram
@@ -149,6 +151,8 @@ sequenceDiagram
note over FeatureScreen: Widget(s) rebuild note over FeatureScreen: Widget(s) rebuild
``` ```
> Figure 4: The flow diagram of data flow in a feature
### Screen(s) ### Screen(s)
Each feature will contain one or more screens. For _most_ features, the screen will be some sort of `Scaffold` with a [state consumer](#state-management) that dictates the current state of the widget(s). The screen is where a user will interact with the application. User and automated actions trigger events to be sent to the state manager, which in turns communicates to the backend via the [API](#feature-api). Each feature will contain one or more screens. For _most_ features, the screen will be some sort of `Scaffold` with a [state consumer](#state-management) that dictates the current state of the widget(s). The screen is where a user will interact with the application. User and automated actions trigger events to be sent to the state manager, which in turns communicates to the backend via the [API](#feature-api).