Fix typos in every DocC-Articles (#1490)

* Fix typos in every DocC-Articles

* Update Sources/ComposableArchitecture/Documentation.docc/Articles/DependencyManagement.md

* Update Sources/ComposableArchitecture/Documentation.docc/Articles/DependencyManagement.md

* Update Sources/ComposableArchitecture/Documentation.docc/Articles/MigratingToTheReducerProtocol.md

Co-authored-by: Stephen Celis <[email protected]>
(cherry picked from commit c5508de7a071fbe6cd24e238a6b07f23c72c9a11)

# Conflicts:
#	Sources/ComposableArchitecture/Documentation.docc/Articles/Testing.md

Author: Jager-yoo

Sources/ComposableArchitecture/Documentation.docc/Articles/Bindings.md

@@ -11,7 +11,7 @@ such communication with your application's store.
 ### Ad hoc bindings
 
 The simplest tool for creating bindings that communicate with your store is 
-``ViewStore/binding(get:send:)-65xes``, which is handed two closures: one that describe how to
+``ViewStore/binding(get:send:)-65xes``, which is handed two closures: one that describes how to
 transform state into the binding's value, and one that describes how to transform the binding's
 value into an action that can be fed back into the store.
 
@@ -197,7 +197,7 @@ struct Settings: ReducerProtocol {
 }
 ```
 
-Each annotated field is directly to bindable to SwiftUI controls, like pickers, toggles, and text
+Each annotated field is directly bindable to SwiftUI controls, like pickers, toggles, and text
 fields. Notably, the `isLoading` property is _not_ annotated as being bindable, which prevents the
 view from mutating this value directly.
 

Sources/ComposableArchitecture/Documentation.docc/Articles/DependencyManagement.md

@@ -11,7 +11,7 @@ to servers, but also seemingly innocuous things such as `UUID` and `Date` initia
 schedulers and clocks, can be thought of as dependencies.
 
 By controlling the dependencies our features need to do their job we gain the ability to completely
-alter the execution context a features runs in. This means in tests and Xcode previews you can 
+alter the execution context a feature runs in. This means in tests and Xcode previews you can 
 provide a mock version of an API client that immediately returns some stubbed data rather than 
 making a live network request to a server.
 
@@ -290,7 +290,7 @@ Further, we highly recommend you consider making your `testValue` dependency int
 call an "unimplemented" dependency. This is a version of your dependency that performs an `XCTFail`
 in each endpoint so that if it is ever invoked in tests it will cause a test failure. This allows
 you to be more explicit about what dependencies are actually needed to test a particular user
-flow in you feature.
+flow in your feature.
 
 For example, suppose you have an API client with endpoints for fetching a list of users or fetching
 a particular user by id:
@@ -471,11 +471,11 @@ which can help a feature to seem less intimidating.
 ## Overriding dependencies
 
 It is possible to change the dependencies for just one particular reducer inside a larger composed
-reducer. This can be handy running a feature in a more controlled environment where it may not be
+reducer. This can be handy when running a feature in a more controlled environment where it may not be
 appropriate to communicate with the outside world.
 
-For example, suppose you want to teach users how to user your feature through on onboarding
-experience. In such an experience it may not be appropriate for the users's actions to cause
+For example, suppose you want to teach users how to use your feature through an onboarding
+experience. In such an experience it may not be appropriate for the user's actions to cause
 data to be written to disk, or user defaults to be written, or any number of things. It would be
 better to use mock versions of those dependencies so that the user can interact with your feature
 in a fully controlled environment.

Sources/ComposableArchitecture/Documentation.docc/Articles/GettingStarted.md

@@ -14,7 +14,7 @@ let package = Package(
   dependencies: [
     .package(
       url: "https://github.com/pointfreeco/swift-composable-architecture",
-      from: "0.41.0"
+      from: "0.42.0"
     ),
   ],
   targets: [
@@ -47,7 +47,7 @@ your domain:
     so that the store can run the reducer and effects, and you can observe state changes in the
     store so that you can update UI.
 
-The benefits of doing this is that you will instantly unlock testability of your feature, and you
+The benefits of doing this are that you will instantly unlock testability of your feature, and you
 will be able to break large, complex features into smaller domains that can be glued together.
 
 As a basic example, consider a UI that shows a number along with "+" and "−" buttons that increment
@@ -95,7 +95,7 @@ struct Feature: ReducerProtocol {
 ```
 
 And then we implement the ``ReducerProtocol/reduce(into:action:)-4nzr2`` method which is responsible 
-for handling the actual logic and  behavior for the feature. It describes how to change the current 
+for handling the actual logic and behavior for the feature. It describes how to change the current 
 state to the next state, and describes what effects need to be executed. Some actions don't need to 
 execute effects, and they can return `.none` to represent that:
 
@@ -244,7 +244,7 @@ class FeatureViewController: UIViewController {
 ```
 
 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 
+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
@@ -358,7 +358,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
@@ -478,6 +478,6 @@ await store.receive(.numberFactResponse(.success("0 is a good number Brent"))) {
 That is the basics of building and testing a feature in the Composable Architecture. There are 
 _a lot_ more things to be explored, such as <doc:DependencyManagement>, <doc:Performance>,
 <doc:SwiftConcurrency> and more about <doc:Testing>. Also, the [Examples][examples] directory has 
-a bunch of projects to explore to see more  advanced usages.
+a bunch of projects to explore to see more advanced usages.
 
 [examples]: https://github.com/pointfreeco/swift-composable-architecture/tree/main/Examples

Sources/ComposableArchitecture/Documentation.docc/Articles/MigratingToTheReducerProtocol.md

@@ -12,7 +12,7 @@ allowing you to plug protocol-style reducers into old-style reducers, and vice-v
 Although we recommend migrating your code when you have time, the newest version of the library
 is still 100% backwards compatible with all previous versions. The ``Reducer`` type is now
 "soft" deprecated, which means we consider it deprecated, and it says so in the documentation, but 
-you will not get any warnings about it. Some time in the future we will officially deprecate it, 
+you will not get any warnings about it. Sometime in the future, we will officially deprecate it, 
 and then sometime even later we will remove it so that we can rename the protocol to `Reducer`.
 
 This article outlines a number of strategies you can employ to convert your reducers to the protocol
@@ -89,7 +89,7 @@ struct Feature: ReducerProtocol {
 }
 ```
 
-Once this feature's domain and reducer is converted to the protocol-style you will invariably have 
+Once this feature's domain and reducer are converted to the protocol-style you will invariably have 
 compiler errors wherever you were referring to the old types. For example, suppose you have a 
 parent feature that is currently trying to embed the old-style domain and reducer into its domain
 and reducer:
@@ -117,7 +117,7 @@ let parentReducer = Reducer<ParentState, ParentAction, ParentEnvironment>.combin
       state: \.feature, 
       action: /ParentAction.feature, 
       environment: {  
-        FeatureAEnvironment(date: $0.date)
+        FeatureEnvironment(date: $0.date)
       }
     ),
 
@@ -144,7 +144,7 @@ enum ParentAction {
 
 And then the `parentReducer` can be fixed by making use of the helper ``AnyReducer/init(_:)-42p1a``
 which aids in converting protocol-style reducers into old-style reducers. It is initialized with a
-closure  that is passed an environment, which is the one thing protocol-style reducers don't have,
+closure that is passed an environment, which is the one thing protocol-style reducers don't have,
 and you  are to return a protocol-style reducer:
 
 ```swift
@@ -174,10 +174,10 @@ leaf node feature to the new ``ReducerProtocol``-style of doing things.
 ## Composition of features
 
 Some features in your application are an amalgamation of other features. For example, a tab-based
-application may have a separate domain and reducer for each tab, and then a app-level domain and
+application may have a separate domain and reducer for each tab, and then an app-level domain and
 reducer that composes everything together.
 
-Suppose that all of the tab features have already be converted to the protocol-style:
+Suppose that all of the tab features have already been converted to the protocol-style:
 
 ```swift
 struct TabA: ReducerProtocol {
@@ -367,10 +367,10 @@ let parentReducer = Reducer<
 Now the question is, how do we migrate `parentReducer` to a protocol conformance?
 
 This gives us an opportunity to improve the correctness of this code. It turns out there is a gotcha 
-with the `optional` operator: it must be run _before_ the parent logic runs. If it is  not, then it 
-is possible for a child action to come into the system, the parent observe the action  and decide to 
-`nil` out the child state, and then the child  reducer will not get a chance to react to the action. 
-This can cause subtle bugs, and so we have documentation advising you to order things  the correct 
+with the `optional` operator: it must be run _before_ the parent logic runs. If it is not, then it 
+is possible for a child action to come into the system, the parent observes the action and decides to 
+`nil` out the child state, and then the child reducer will not get a chance to react to the action.
+This can cause subtle bugs, and so we have documentation advising you to order things the correct 
 way, and if we detect a child action while state is `nil` we display a runtime warning.
 
 A `Parent` reducer conformances can be made by implementing the 

Sources/ComposableArchitecture/Documentation.docc/Articles/Performance.md

@@ -195,7 +195,7 @@ struct AppView: View {
 }
 ```
 
-This gives you maximum flexibilty in the future for adding new fields to `ViewState` without making
+This gives you maximum flexibility in the future for adding new fields to `ViewState` without making
 your view convoluated.
 
 This technique for reducing view re-computations is most effective towards the root of your app
@@ -209,8 +209,8 @@ store.
 ### Sharing logic with actions
 
 There is a common pattern of using actions to share logic across multiple parts of a reducer.
-This is an ineffecient way to share logic. Sending actions is not as lightweight of an operation
-as, say, caling a method on a class. Actions travel through multiple layers of an application, and 
+This is an inefficient way to share logic. Sending actions is not as lightweight of an operation
+as, say, calling a method on a class. Actions travel through multiple layers of an application, and 
 at each layer a reducer can intercept and reinterpret the action.
 
 It is far better to share logic via simple methods on your ``ReducerProtocol`` conformance.
@@ -263,8 +263,7 @@ be if only a single action was sent.
 Besides just performance concerns, there are two other reasons why you should not follow this 
 pattern. First, this style of sharing logic is not very flexible. Because the shared logic is 
 relegated to a separate action it must always be run after the initial logic. But what if
-instead you need to run some shared logic _before_ the core logic? This style cannot accomodate
-for that.
+instead you need to run some shared logic _before_ the core logic? This style cannot accommodate that.
 
 Second, this style of sharing logic also muddies tests. When you send a user action you have to 
 further assert on receiving the shared action and assert on how state changed. This bloats tests
@@ -301,7 +300,7 @@ So, we do not recommend sharing logic in a reducer by having dedicated actions f
 and executing synchronous effects.
 
 Instead, we recommend sharing logic with methods defined in your feature's reducer. The method has
-full access to all depedencies, it can take an `inout State` if it needs to make mutations to 
+full access to all dependencies, it can take an `inout State` if it needs to make mutations to 
 state, and it can return an `Effect<Action, Never>` if it needs to execute effects.
 
 The above example can be refactored like so:
@@ -430,7 +429,7 @@ calls that one does with classes, such as `ObservableObject` conformances. When
 into the system there are multiple layers of features that can intercept and interpret it, and 
 the resulting state changes can reverberate throughout the entire application.
 
-Because of this, sending actions do come with a cost. You should aim to only send "significant" 
+Because of this, sending actions does come with a cost. You should aim to only send "significant" 
 actions into the system, that is, actions that cause the execution of important logic and effects
 for your application. High-frequency actions, such as sending dozens of actions per second, 
 should be avoided unless your application truly needs that volume of actions in order to implement
@@ -486,7 +485,7 @@ incurring unnecessary costs for sending actions.
 
 In very large SwiftUI applications you may experience degraded compiler performance causing long
 compile times, and possibly even compiler failures due to "complex expressions." The
-``WithViewStore``  helpers that comes with the library can exacerbate that problem for very complex
+``WithViewStore``  helpers that come with the library can exacerbate that problem for very complex
 views. If you are running into issues using ``WithViewStore`` you can make a small change to your
 view to use an `@ObservedObject` directly.
 

Sources/ComposableArchitecture/Documentation.docc/Articles/SwiftConcurrency.md

@@ -71,7 +71,7 @@ return .task { [count = state.count] in
 ### Accessing dependencies in an effect
 
 In the Composable Architecture, one provides dependencies to a reducer so that it can interact with
-the outside world in a determinstic and controlled manner. Those dependencies can be used from
+the outside world in a deterministic and controlled manner. Those dependencies can be used from
 asynchronous and concurrent contexts, and so must be `Sendable`.
 
 If your dependency is not sendable, you will be notified at the time of registering it with the
@@ -101,5 +101,5 @@ struct FactClient {
 }
 ```
 
-This will restrict the kinds of closures that can be used when construct `FactClient` values, thus 
+This will restrict the kinds of closures that can be used when constructing `FactClient` values, thus 
 making the entire `FactClient` sendable itself.

Sources/ComposableArchitecture/Documentation.docc/Articles/Testing.md

@@ -21,35 +21,35 @@ then assert on how it changed after, like this:
 
 ```swift
 struct Feature: ReducerProtocol {
-struct State: Equatable { var count = 0 }
-enum Action { case incrementButtonTapped, decrementButtonTapped }
+  struct State: Equatable { var count = 0 }
+  enum Action { case incrementButtonTapped, decrementButtonTapped }
 
   func reduce(into state: inout State, action: Action) -> Effect<Action, Never> {
-  switch action {
-  case .incrementButtonTapped:
-    state.count += 1
-    return .none
-  case .decrementButtonTapped:
-    state.count -= 1
-    return .none
+    switch action {
+    case .incrementButtonTapped:
+      state.count += 1
+      return .none
+    case .decrementButtonTapped:
+      state.count -= 1
+      return .none
+    }
   }
 }
-}
 
 func testBasics() {
   let feature = Feature()
   var currentState = Feature.State(count: 0)
   _ = feature.reduce(into: &currentState, action: .incrementButtonTapped)
-XCTAssertEqual(
-  currentState,
-  State(count: 1)
-)
+  XCTAssertEqual(
+    currentState,
+    State(count: 1)
+  )
 
   _ = feature.reduce(into: &currentState, action: .decrementButtonTapped)
-XCTAssertEqual(
-  currentState,
-  State(count: 0)
-)
+  XCTAssertEqual(
+    currentState,
+    State(count: 0)
+  )
 }
 ```
 
@@ -182,34 +182,34 @@ Effects form a major part of a feature's logic. They can perform network request
 services, load and save data to disk, start and stop timers, interact with Apple frameworks (Core
 Location, Core Motion, Speech Recognition, etc.), and more.
 
-As a simple example, suppose we have a feature with a button such that when you tap it it starts
+As a simple example, suppose we have a feature with a button such that when you tap it, it starts
 a timer that counts up until you reach 5, and then stops. This can be accomplished using the
-``Effect/run(priority:operation:catch:file:fileID:line:)`` helper, which provides you an
+``Effect/run(priority:operation:catch:file:fileID:line:)`` helper, which provides you with an
 asynchronous context to operate in and can send multiple actions back into the system:
 
 ```swift
 struct Feature: ReducerProtocol {
-struct State: Equatable { var count = 0 }
-enum Action {  case startTimerButtonTapped, timerTick }
+  struct State: Equatable { var count = 0 }
+  enum Action {  case startTimerButtonTapped, timerTick }
   enum TimerID {}
 
   func reduce(into state: inout State, action: Action) -> Effect<Action, Never> {
-  switch action {
-  case .startTimerButtonTapped:
-    state.count = 0
-    return .run { send in
-      for _ in 1...5 {
+    switch action {
+    case .startTimerButtonTapped:
+      state.count = 0
+      return .run { send in
+        for _ in 1...5 {
           try await Task.sleep(for: .seconds(1))
-        await send(.timerTick)
+          await send(.timerTick)
+        }
       }
-    }
 
-  case .timerTick:
-    state.count += 1
-    return .none
+    case .timerTick:
+      state.count += 1
+      return .none
+    }
   }
 }
-}
 ```
 
 To test this we can start off similar to how we did in the [previous section][Testing-state-changes]
@@ -304,7 +304,7 @@ await store.receive(.timerTick, timeout: .seconds(2)) {
 Now the full test suite passes, and we have exhaustively proven how effects are executed in this
 feature. If in the future we tweak the logic of the effect, like say have it emit 10 times instead 
 of 5, then we will immediately get a test failure letting us know that we have not properly 
-asserted on how the features evolves over time.
+asserted on how the features evolve over time.
 
 However, there is something not ideal about how this feature is structured, and that is the fact
 that we are doing actual, uncontrolled time-based asynchrony in the effect: