Delete commented-out code

Sources/ComposableArchitecture/Documentation.docc/Tutorials/BuildingSyncUps/02-ListsOfSyncUps/ListsOfSyncUps.tutorial

@@ -52,51 +52,7 @@
         [identified-array-gh]: http://github.com/pointfreeco/swift-identified-collections
 
         @Code(name: "Models.swift", file: ListsOfSyncUps-01-code-0003.swift)
-      }
-
-      <!--
-      NB: Removing the Tagged discussion for now because it was too confusing for readers.
-
-      There's another improvement that can be made to our domain models, but this one is completely
-      optional.
-
-      Right now all of the IDs of our models are `UUID`. This means it is technically possible to
-      do something non-sensical like check if a `syncUp.id` is equal to an `attendee.id`. That is
-      never a valid thing to do, and so it would be ideal if we could detect that at _compile time_,
-      rather than runtime.
-
-      We can do this by leveraging one of our other libraries, [Tagged][tagged-gh]. This library
-      does not automatically come with the Composable Architecture, and so you will need to add it,
-      and these next steps are completely optional for the purpose of this tutorial.
-
-      [tagged-gh]: http://github.com/pointfreeco/swift-tagged
-
-      @Step {
-        Add the `Tagged` library to your project by navigating to the build settings, and then to
-        the package dependencies tab, and input the GitHub URL:
-        [https://github.com/pointfreeco/swift-tagged](https://github.com/pointfreeco/swift-tagged).
-
-        @Image(source: syncups-02-package-dependencies-tagged.png)
-      }
-
-      @Step {
-        Go back to Models.swift, and import the `Tagged` library, and upgrade all usages of a plain
-        `UUID` to be a tagged `UUID`.
-
-        > Note: The tag can even just be `Self`, but you can also have multiple tagged values in a
-        > model by created dedicated tagged types. See the [Tagged repo][tag-collisions-gh] for more
-        > information.
-
-        [tag-collisions-gh]: https://github.com/pointfreeco/swift-tagged#handling-tag-collisions
-
-        @Code(name: "Models.swift", file: ListsOfSyncUps-01-code-0004.swift)
-      }
-      > Important: To keep things simple for the rest of this tutorial we will _not_ assume that
-      you have implemented the `Tagged` type into your domain. If you choose to use `Tagged` then
-      you will need to do some extra work to construct tagged values that is not covered in
-      the tutorial. For example, once we get to using dependencies to control UUIDs, you will need
-      to write `Attendee.ID(uuid())` instead of just `uuid()`.
-      -->
+      }      
     }
   }
 

Sources/ComposableArchitecture/Documentation.docc/Tutorials/BuildingSyncUps/06-SyncUpDetail/TestingSyncUpDetail.tutorial

@@ -69,79 +69,5 @@
       It is also possible to shorten this test quite a bit by using a non-exhaustive test store, as
       we did in <doc:PresentingSyncUpForm>, but we will leave that as an exercise for the reader.
     }
-  }
-
-  <!--
-  This is all old now that we are using @Shared and deleting directly in the reducer. We can
-  either omit this or update it.
-
-  @Section(title: "Testing the delete flow") {
-    @ContentAndMedia {
-      Next we will test the flow of the user deleting the sync-up. This involves asserting that the
-      confirmation alert shows, and emulating the user interacting with the alert.
-    }
-
-    @Steps {
-      @Step {
-        Create a new test method for testing the delete user flow. Also create a 
-        ``ComposableArchitecture/TestStore`` for the `SyncUpDetail` feature.
-
-        @Code(name: "SyncUpDetailTests.swift", file: TestingSyncUpDetail-02-code-0001.swift, previousFile: TestingSyncUpDetail-02-code-0001-previous.swift)
-      }
-
-      @Step {
-        Emulate the user tapping the "Delete" button and assert that the alert state is populated.
-
-        Run the test suite to confirm that it passes.
-
-        @Code(name: "SyncUpDetailTests.swift", file: TestingSyncUpDetail-02-code-0002.swift)
-      }
-
-      @Step {
-        Emulate the user confirming deletion of the sync-up by sending a deeply nested action to the
-        `.destination`, when it is `.presented`, in the `.alert` case, and then finally the
-        `.confirmButtonTapped` action. Also assert that the alert will be dismissed by setting the
-        `destination` state to `nil`.
-
-        TODO: Make alert action case-pathable
-
-        @Code(name: "SyncUpDetailTests.swift", file: TestingSyncUpDetail-02-code-0003.swift)
-      }
-
-      @Step {
-        Run the test suite again to see that now it does _not_ pass. We have a test failure.
-
-        @Code(name: "SyncUpDetailTests.swift", file: TestingSyncUpDetail-02-code-0004.swift)
-      }
-
-      This failure is happening because we are now making use effects that emit actions, and by
-      default the ``ComposableArchitecture/TestStore`` forces us to assert on _everything_ happening
-      in the feature. This is really great because it helps us catch potential problems when new
-      logic and behavior is added to our features.
-
-      The failure is letting us know that the system received an action that we did not
-      assert against. This is also a great failure to have because it forces us to prove that we
-      know how effects execute and feed their data back in the system.
-
-      Let's fix this test failure by asserting on more of what is happening in the system. 
-
-      @Step {
-        Use the ``ComposableArchitecture/TestStore/receive(_:_:timeout:assert:file:line:)-dkei``
-        method to assert that we expect to receive a delegate action to delete the sync-up.
-
-        Run the test suite to see that one of the previous two test failures has now been fixed.
-
-        > Note: We are using case key path composition in order to describe the deeply nested action
-        > that is being received.
-
-        @Code(name: "SyncUpDetailTests.swift", file: TestingSyncUpDetail-02-code-0005.swift)
-      }
-
-      Now that this test passes we have definitively proven that
-      the `.deleteSyncUp` delegate action is sent when the user confirms deletion of the sync-up.
-      That will communicate to the parent that it should finish deleting the sync-up _and_ it should
-      dismiss the presented sheet.
-    }
-  }
-  -->
+  }  
 }