Skip to content

Commit

Permalink
Update README.md
Browse files Browse the repository at this point in the history
  • Loading branch information
MaximBazarov authored Aug 3, 2023
1 parent a34f39d commit 124fcd4
Showing 1 changed file with 0 additions and 64 deletions.
64 changes: 0 additions & 64 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -23,70 +23,6 @@ Additionaly **DecideTesting** provides tools to replace the environment and trac

## Dependency Injection


# Decide

Decide designed to manage state and side-effects, specifically tailored for Swift developers. It is compatible with SwiftUI, but it goes a step further by extending state management beyond the SwiftUI view context.

The library addresses some of the limitations found [in SwiftUI's `@State` and `Binding`](https://developer.apple.com/documentation/swiftui/binding) and [Combine's @Published](https://developer.apple.com/documentation/combine/published/) approach, providing a solution for defining state outside of a SwiftUI view, a feature that is currently lacking in SwiftUI.

Moreover, "Decide" offers a solution for unidirectional state updates and side-effect management, another area where SwiftUI falls short. Importantly, the library is not limited to SwiftUI and can be used in any non-SwiftUI code.

## Key Features

- **SwiftUI Compatibility:** Decide is designed to seamlessly integrate with SwiftUI, enhancing its state management capabilities beyond the SwiftUI view context.

- **State Declaration:** This feature decouples state declarations from view contexts, providing a way to declare them independently. Unlike `@Published` or `@State`, it doesn't require an instance of the ViewModel or View. Instead, it uses environment and KeyPaths to access the value.
- It offers `AtomicState` or `KeyedState` classes for group ability and `@Property` to define the name, type, and default value of the state, which is an extended version of SwiftUI's `@State`.
- It supports both mutable and immutable properties.
- It introduces `Computation`, a type of state that is computed based on other states and is recomputed when one or more of them change.
- Keyed States allow for the creation of atomic states that can differentiate based on a `Key`. This is ideal for lists or collections of items that are identical but differentiated by ID or any other key.

## How to Use

### Declaring State

Decide introduces `@Property` as a way to describe the atomic observable value in the environment. This is similar to SwiftUI's `@State`, but it allows for a more atomic standalone state definition:

```swift
final class TodoList: AtomicState {

// \.TodoList.$networking <- property key path
@DefaultInstance var networking: Networking = URLSession.shared

// \.TodoList.$selectedItemID <- property key path
@Property var selectedItemID: Item.ID?


/// Nested keyed state
final class FeatureFlag: KeyedState<String> {
// \.TodoList.FeatureFlag.$isEnabled <- property key path
// requires access by id e.g. isEnabled[id]
@Property var isEnabled: Bool = false
}
}
```

## Nesting
You can nest state declarations to better define your state by creating a new state within another one or extending it. This doesn't have any effect other than a name change. So, if you decide to restructure your state later, you only need to move properties where they belong and update keypaths that have been used.

### Keyed State

`KeyedState` is an enhancement for cases where the state is atomic but differentiates depending on a `Key`, such as a list of products, each with its own unique ID. This state is accessed like a dictionary:

```swift

@Bind(\TodoList.FeatureFlag.$isEnabled) var isFeatureEnabled

var body: some View {
if isFeatureEnabled[myFeatureName] {
...
}
}

```


# Decide Testing
- a library that makes testing of Decide-based code easier by providing convenient syntax sugar.
- [ ] Recursive Override Of Environment
Expand Down

0 comments on commit 124fcd4

Please sign in to comment.