Skip to content

Fix typos in new Reducer Protocol README #1475

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Oct 12, 2022
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -257,7 +257,7 @@ It is also straightforward to have a UIKit controller driven off of this store.
```
</details>

Once we are ready to display this view, for example in the app's entry point, we can construct a store. This can be done by specify the initial state to start the application in, as well as the reducer that will power the application:
Once we are ready to display this view, for example in the app's entry point, we can construct a store. This can be done by specifying the initial state to start the application in, as well as the reducer that will power the application:

```swift
@main
Expand Down Expand Up @@ -315,7 +315,7 @@ await store.receive(.numberFactResponse(.success(???))) {

However, how do we know what fact is going to be sent back to us?

Currently our reducer is using an effect that reaches out into the real world to hit an API server, and that means we have no way to control its behavior. We are at the whims of our internet connectivity and the availabilty of the API server in order to write this test.
Currently our reducer is using an effect that reaches out into the real world to hit an API server, and that means we have no way to control its behavior. We are at the whims of our internet connectivity and the availability of the API server in order to write this test.

It would be better for this dependency to be passed to the reducer so that we can use a live dependency when running the application on a device, but use a mocked dependency for tests. We can do this by adding a property to the `Feature` reducer:

Expand Down Expand Up @@ -357,7 +357,7 @@ struct MyApp: App {
}
```

But in tests we can use a mock dependency that immediately returns a determinstic, predictable fact:
But in tests we can use a mock dependency that immediately returns a deterministic, predictable fact:

```swift
@MainActor
Expand Down Expand Up @@ -501,7 +501,7 @@ You can add ComposableArchitecture to an Xcode project by adding it as a package
2. Enter "https://github.com/pointfreeco/swift-composable-architecture" into the package repository URL text field
3. Depending on how your project is structured:
- If you have a single application target that needs access to the library, then add **ComposableArchitecture** directly to your application.
- If you want to use this library from multiple Xcode targets, or mixing Xcode targets and SPM targets, you must create a shared framework that depends on **ComposableArchitecture** and then depend on that framework in all of your targets. For an example of this, check out the [Tic-Tac-Toe](./Examples/TicTacToe) demo application, which splits lots of features into modules and consumes the static library in this fashion using the **tic-tac-toe** Swift package.
- If you want to use this library from multiple Xcode targets, or mix Xcode targets and SPM targets, you must create a shared framework that depends on **ComposableArchitecture** and then depend on that framework in all of your targets. For an example of this, check out the [Tic-Tac-Toe](./Examples/TicTacToe) demo application, which splits lots of features into modules and consumes the static library in this fashion using the **tic-tac-toe** Swift package.

## Help

Expand Down