Fix typo in the "Meet the Composable Architecture" tutorial (#2114)

* Fix typo

* Update Sources/ComposableArchitecture/Documentation.docc/Tutorials/01-YourFirstFeature.tutorial

* Update Sources/ComposableArchitecture/Documentation.docc/Tutorials/03-TestingYourFeature.tutorial

---------

Co-authored-by: Stephen Celis <[email protected]>

Author: redryerye

Sources/ComposableArchitecture/Documentation.docc/Tutorials/01-YourFirstFeature.tutorial

@@ -36,7 +36,7 @@
         To conform to ``ComposableArchitecture/ReducerProtocol`` you will start with a domain 
         modeling exercise. You will create a `State` type that holds the state your feature needs 
         to do its job, typically a struct. Then you will create an `Action` type that holds all 
-        the actions the user can perform  in the feature, typically an enum. 
+        the actions the user can perform in the feature, typically an enum. 
 
         @Code(name: "CounterFeature.swift", file: 01-01-code-0003.swift)
       }
@@ -74,7 +74,7 @@
         to the state's count. We must also return a value of ``ComposableArchitecture/EffectTask`` 
         that represents the effect to be executed in the outside world, but in this case we do not 
         need to execute anything. So we can return a special
-        ``ComposableArchitecture/EffectPublisher/none`` value to represents we have no effects to
+        ``ComposableArchitecture/EffectPublisher/none`` value to represent we have no effects to
         execute.
 
         @Code(name: "CounterFeature.swift", file: 01-01-code-0006.swift)
@@ -116,7 +116,7 @@
       }
 
       @Step {
-        Next we can implement some basic view heirarchy for displaying the count and providing 
+        Next, we can implement some basic view hierarchy for displaying the count and providing 
         buttons for incrementing and decrementing. 
 
         > Note: You cannot read state from a ``ComposableArchitecture/Store`` directly, nor can you 
@@ -134,7 +134,7 @@
       With some basic view scaffolding in place we can now start actually observing state in the
       `store`. This is done by constructing a ``ComposableArchitecture/ViewStore``, and for 
       SwiftUI views there is a convenience view called a ``ComposableArchitecture/WithViewStore``
-      that provides a lightweight syntax for construct a view store.
+      that provides a lightweight syntax for constructing a view store.
 
       @Step {  
         View stores require that `State` be `Equatable`, so we must do that first. Once the view 
@@ -164,7 +164,7 @@
       }
 
       Before moving onto the next section, let's quickly show off a super power of the Composable
-      Architecture. Because all of the feature's logic and behavior is contained in the reducer,
+      Architecture. Because all of the feature's logic and behavior are contained in the reducer,
       we can run the preview with a completely different reducer to alter how it executes.
 
       @Step {  

Sources/ComposableArchitecture/Documentation.docc/Tutorials/02-AddingSideEffects.tutorial

@@ -8,13 +8,13 @@
     @ContentAndMedia {
       Side effects are by far the most important aspect of feature development. They are what allow
       us to communicate with the outside world, such as making API requests, interacting with file 
-      systems, and performing time-based asynchrony. Without them our applications could not do
+      systems, and performing time-based asynchrony. Without them, our applications could not do
       anything of real value for our users.
 
       However, side effects are also the most complex part of our features. State mutations are 
-      simple processes. If you run the reducer with the same piece of state and same action you will
+      simple processes. If you run the reducer with the same piece of state and same action, you will
       always get the same result. But effects are susceptible to the vagaries of the outside world, 
-      such as network connectivity, disk permissions, and more. Each time you run an effect you
+      such as network connectivity, disk permissions, and more. Each time you run an effect, you
       can get back a completely different answer.
 
       Let's start by seeing why we can't simply perform effectful work directly in our 
@@ -42,7 +42,7 @@
       @Step {
         We will also add a progress view at the bottom to display while we are loading the fact,
         and we will unwrap a bit of optional state to display the fact. We are using the
-        `isLoading` and `fact` state to accomplish this, neither of which exist in the counter 
+        `isLoading` and `fact` state to accomplish this, neither of which exists in the counter 
         feature yet, but will soon.
 
         @Code(name: "CounterFeature.swift", file: 02-01-code-0002.swift)
@@ -63,7 +63,7 @@
         Let's add the additional state and actions that have been dictated to us by the view.
         We know we need some `fact` and `isLoading` state, and we need a `factButtonTapped` action.
         We can also implement that action in the reducer by flipping `isLoading` to `true`, and 
-        we'll clear the `fact` state when any button is tapped. And finally we will return `.none` 
+        we'll clear the `fact` state when any button is tapped. And finally, we will return `.none` 
         just like we did in all the other cases.
 
         @Code(name: "CounterFeature.swift", file: 02-01-code-0004.swift)
@@ -82,7 +82,7 @@
 
       The Composable Architecture separates the simple, pure transformations of state from the 
       complex, messy side effects. It is one of the core tenets of the library and there are a lot 
-      of benefits to doing so. Luckily for us the library gives us a tool that is appropriate
+      of benefits to doing so. Luckily for us, the library gives us a tool that is appropriate
       for executing side effects. It is called ``ComposableArchitecture/EffectTask`` and it is
       explored in the next section.
     }
@@ -214,7 +214,7 @@
       "Stop timer", we will see that the timer did not stop.
 
       @Step {
-        To fix the bug we can leverage a powerful feature of the Composable Architecture known as 
+        To fix the bug, we can leverage a powerful feature of the Composable Architecture known as 
         "effect cancellation". We can mark any effect as cancellable using the 
         ``ComposableArchitecture/EffectPublisher/cancellable(id:cancelInFlight:)-29q60`` method
         by providing an ID, and then at a later time we can cancel that effect using 

Sources/ComposableArchitecture/Documentation.docc/Tutorials/03-TestingYourFeature.tutorial

@@ -1,7 +1,7 @@
 @Tutorial(time: 60) {
   @Intro(title: "Testing your feature") {
     Learn how to write test for the counter built in previous tutorials, including how to assert 
-    against  state changes and how effects execute and feed data back into the system.
+    against state changes and how effects execute and feed data back into the system.
   }
 
   @Section(title: "Testing state changes") {
@@ -34,7 +34,7 @@
       }
 
       @Step {
-        Next we will create a ``ComposableArchitecture/TestStore``, which is a tool that makes it 
+        Next, we will create a ``ComposableArchitecture/TestStore``, which is a tool that makes it 
         easy to assert on how the behavior of your feature changes as actions are sent into the 
         system. You create a test store in the same way you create a 
         ``ComposableArchitecture/Store``, by providing some initial state to start the feature in
@@ -57,10 +57,10 @@
 
       @Step {
         Run the test by typing cmd+U or clicking the test diamond next to the test method.
-        Unfortunately you will find that the test fails. This is because each time you send an
+        Unfortunately, you will find that the test fails. This is because each time you send an
         action to a ``ComposableArchitecture/TestStore`` you must also describe exactly how the
         state changes after that action is sent. The library also helpfully shows you a detailed
-        failure message showing you exactly how state differed from what you expect (the lines
+        failure message showing you exactly how state differed from what you expected (the lines
         with the minus "-") and the actual value (the lines with the plus "+").
 
         @Code(name: "CounterFeatureTests.swift", file: 03-01-code-0004.swift)
@@ -96,7 +96,7 @@
       the effects it returns that are then processed by the store.
 
       Writing tests against side effects takes a lot more work since you typically have to 
-      control you dependency on external systems and then provide test-friendly versions of those
+      control your dependency on external systems and then provide test-friendly versions of those
       dependencies for tests. Let's start by testing the timer functionality of our feature, 
       which turns out to be a little easier to test than the network request for fetching a number
       fact.
@@ -163,7 +163,7 @@
       @Step {
         Run tests to see that, unfortunately, the test fails. This is happening because our timer
         takes a full second to emit, but the test store will only wait around for a small amount
-        of time to receive an action, and if it doesn't it creates a test failure. This is 
+        of time to receive an action, and if it doesn't, it creates a test failure. This is 
         because the test store doesn't want your tests to be slow, and so rather you take control
         over your dependency on time to write a faster, more deterministic test.