Skip to content

Commit

Permalink
Readme typos fix and update (#101)
Browse files Browse the repository at this point in the history 
* fixed typos

* readme update
  • Loading branch information
@KazaiMazai
KazaiMazai authored Sep 10, 2024
1 parent 4bc8fe0 commit 99b6646
Show file tree
Hide file tree
Showing 3 changed files with 94 additions and 52 deletions.
130 changes: 86 additions & 44 deletions README.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -202,30 +202,73 @@ final class MyViewController: ViewController {

## Hierarchical Stores Tree Architecture

Puredux allows you to build a hierarchical store tree. This architecture facilitates building applications where state can be shared or isolated, while state mutations remain predictable.
Puredux allows you to build a hierarchical store tree, facilitating the development of applications where state can be either shared or isolated, while keeping state mutations predictable.

Actions are propagated upstream from child stores to the root store,
while state updates flow downstream from the root store to child stores and, ultimately, to store observers.
Actions propagate upstream from child stores to the root store, while state updates flow downstream from the root store to child stores, and ultimately to store observers.


The store tree hierarchy ensures that business logic is completely decoupled from the UI layer. This allows for a deep, isolated business logic tree while maintaining a shallow UI layer focused solely on its responsibilities.
The store tree hierarchy ensures that business logic is fully decoupled from the UI layer. This allows for a deep, isolated business logic tree, while maintaining a shallow UI layer focused solely on its responsibilities.

Make your app driven by business logic, not by the view hierarchy.

Puredux provides flexibility in structuring your app with the following options:

- Single Store
- Multiple Independent Stores
- Multiple Store Tree

The multiple store tree is a flexible design that handles complex applications by organizing stores in a hierarchical structure. This approach offers several benefits:

- **Feature scope isolation**: Each feature or module has its own dedicated store, preventing cross-contamination of state.
- **Performance optimization**: Stores can be made pluggable and isolated, reducing the overhead of managing a large, monolithic state and improving performance.
- **Scalable application growth**: You can start with a simple structure and add more stores as your application grows, making this approach sustainable for long-term development.


```swift
// Root Store Config

// Root Store Configuration
let root = StateStore<AppState, Action>(AppState()) { state, action in state.reduce(action) }
let root = StateStore<AppState, Action>(AppState()) { state, action in
state.reduce(action)
}
.effect(\.effectState) { state, dispatch in
Effect {
// ...
}
}

// FeatureOne Store Configuration
let featureOne = root.with(FeatureOne()) { state, action in state.reduce(action) }
// Feature One Config

// FeatureTwo Stores Configuration
let featureTwo = root.with(FeatureTwo()) { state, action in state.reduce(action) }
let featureOne = root.with(FeatureOne()) { appState, action in
state.reduce(action)
}
.effect(\.effectState) { state, dispatch in
Effect {
// ...
}
}

let screenOne = featureTwo.with(ScreenOne()) { state, action in state.reduce(action) }
// Feature Two Config with 2 screen stores

let screenTwo = featureTwo.with(ScreenTwo()) { state, action in state.reduce(action) }
let featureTwo = root.with(FeatureTwo()) { state, action in
state.reduce(action)
}
.effect(\.effectState) { state, dispatch in
Effect {
// ...
}
}

let screenOne = featureTwo.with(ScreenOne()) { state, action in
state.reduce(action)
}
.effect(\.effectState) { state, dispatch in
Effect {
// ...
}
}

let screenTwo = featureTwo.with(ScreenTwo()) { state, action in
state.reduce(action)
}

```

Expand All @@ -234,38 +277,37 @@ We can connect UI to any of the stores and will end up with the following hierar
<details><summary>Click to expand</summary>
<p>

```text
+----------------+
| AppState Store |
+-------+--------+
|
|
|
+------------------+-------------------+
| |
| |
| |
| |
+------------------+ +------------------+
| FeatureOne Store | | FeatureTwo Store |
+------------------+ +--------+---------+
| |
+----+ |
| UI | +------------+------------+
+----+ | |
| |
| |
| |
+------+----------+ +------+----------+
| ScreenOne Store | | ScreenTwo Store |
+-----------------+ +-----------------+
| |
+----+ +----+
| UI | | UI |
+----+ +----+

```text
+----------------+ +--------------+
| AppState Store | -- | Side Effects |
+----------------+ +--------------+
|
|
+------------+-------------------------+
| |
| |
| |
| |
+------------------+ +------------------+ +--------------+
| FeatureOne Store | | FeatureTwo Store | -- | Side Effects |
+------------------+ +------------------+ +--------------+
| | |
+----+ +--------------+ |
| UI | | Side Effects | +------------+------------+
+----+ +--------------+ | |
| |
| |
| |
+-----------------+ +-----------------+
| ScreenOne Store | | ScreenTwo Store |
+-----------------+ +-----------------+
| | |
+----+ +--------------+ +----+
| UI | | Side Effects | | UI |
+----+ +--------------+ +----+
```


</p>
</details>

Expand All @@ -279,7 +321,7 @@ In the context of UDF architecture, "side effects" refer to asynchronous operati
- Timer Events: Handling delays, timeouts, or scheduled tasks.
- Location Service Callbacks: Responding to changes in location data or retrieving location-specific information.

In the Puredix framework, managing these side effects is achieved through two main mechanisms:
In the Puredux framework, managing these side effects is achieved through two main mechanisms:
- Async Actions
- State-Driven Side Effects

Expand Down
14 changes: 7 additions & 7 deletions Sources/Puredux/Documentation.docc/Articles/ApplicationStoresArchitecture.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -3,10 +3,10 @@
Puredux allows you to build a hierarchical store tree. This architecture facilitates building applications where state can be shared or isolated, while state mutations remain predictable.

## Overview

Actions are propagated upstream from child stores to the root store,
while state updates flow downstream from the root store to child stores and, ultimately, to store observers.


The store tree hierarchy ensures that business logic is completely decoupled from the UI layer. This allows for a deep, isolated business logic tree while maintaining a shallow UI layer focused solely on its responsibilities.

Make your app driven by business logic, not by the view hierarchy.
Expand Down Expand Up @@ -62,7 +62,7 @@ Here is a tree hierarchy example below.
let root = StateStore<AppState, Action>(AppState()) { state, action in
state.reduce(action)
}
.effect(\.effectState) { appState, dispatch in
.effect(\.effectState) { state, dispatch in
Effect {
// ...
}
Expand All @@ -75,7 +75,7 @@ let root = StateStore<AppState, Action>(AppState()) { state, action in
let featureOne = root.with(FeatureOne()) { appState, action in
state.reduce(action)
}
.effect(\.effectState) { appState, dispatch in
.effect(\.effectState) { state, dispatch in
Effect {
// ...
}
Expand All @@ -89,7 +89,7 @@ let featureOne = root.with(FeatureOne()) { appState, action in
let featureTwo = root.with(FeatureTwo()) { state, action in
state.reduce(action)
}
.effect(\.effectState) { appState, dispatch in
.effect(\.effectState) { state, dispatch in
Effect {
// ...
}
Expand All @@ -98,7 +98,7 @@ let featureTwo = root.with(FeatureTwo()) { state, action in
let screenOne = featureTwo.with(ScreenOne()) { state, action in
state.reduce(action)
}
.effect(\.effectState) { appState, dispatch in
.effect(\.effectState) { state, dispatch in
Effect {
// ...
}
Expand All @@ -112,9 +112,9 @@ let screenTwo = featureTwo.with(ScreenTwo()) { state, action in

At this point, we've built an app structure consisting of a shared state, two independent features, and added two screen states to the second feature. We've also connected side effects to them, integrating everything together.

Puredix essentially allows us to build a fully functioning app and control it by dispatching actions—all without the need for an actual UI or even a single mock.
Puredux essentially allows us to build a fully functioning app and control it by dispatching actions—all without the need for an actual UI or even a single mock.

This is a powerful Puredix feature, enabling the testing of interactions between different modules and components of an application to ensure they work correctly at almost any scope: the whole app, a specific feature, or even an individual screen.
This is a powerful Puredux feature, enabling the testing of interactions between different modules and components of an application to ensure they work correctly at almost any scope: the whole app, a specific feature, or even an individual screen.

For the real app, we would also connect the UI to stores, transforming it into an app with the following architecture:

Expand Down
2 changes: 1 addition & 1 deletion Sources/Puredux/Documentation.docc/Articles/SideEffects.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -14,7 +14,7 @@ In the context of UDF architecture, "side effects" refer to asynchronous operati

## Handling Side Effects in Puredux

In the Puredix framework, managing these side effects is achieved through two main mechanisms:
In the Puredux framework, managing these side effects is achieved through two main mechanisms:
- Async Actions
- State-Driven Side Effects

Expand Down

0 comments on commit 99b6646

Please sign in to comment.