wip

Author: mbrandonw

Sources/ComposableArchitecture/Dependencies/Dismiss.swift

@@ -69,22 +69,7 @@ public struct DismissEffect: Sendable {
     fileID: StaticString = #fileID,
     line: UInt = #line
   ) async {
-    guard let dismiss = self.dismiss
-    else {
-      runtimeWarn(
-        """
-        A reducer requested dismissal at "\(fileID):\(line)", but couldn't be dismissed. …
-
-        This is generally considered an application logic error, and can happen when a reducer \
-        assumes it runs in a presentation context. If a reducer can run at both the root level \
-        of an application, as well as in a presentation destination, use \
-        @Dependency(\\.isPresented) to determine if the reducer is being presented before calling \
-        @Dependency(\\.dismiss).
-        """
-      )
-      return
-    }
-    dismiss()
+    await self.callAsFunction(animation: nil, fileID: fileID, line: line)
   }
 
   @MainActor

Sources/ComposableArchitecture/Reducer/Reducers/PresentationReducer.swift

@@ -198,7 +198,7 @@ extension ReducerProtocol {
   ///     * When a ``PresentationAction/dismiss`` action is sent, it runs the parent feature
   ///       before the child state is `nil`'d out. This gives the parent feature an opportunity to
   ///       inspect the child state one last time before the state is cleared.
-  ///     * When a ``PresentationAction/presented(_:)`` action is sent it runs runs the
+  ///     * When a ``PresentationAction/presented(_:)`` action is sent it runs the
   ///       child first, and then the parent. If the order was reversed, then it would be possible
   ///       for the parent feature to `nil` out the child state, in which case the child feature
   ///       would not be able to react to that action. That can cause subtle bugs.

Sources/ComposableArchitecture/Reducer/Reducers/StackReducer.swift

@@ -9,7 +9,9 @@ import OrderedCollections
 ///
 /// See the dedicated article on <doc:Navigation> for more information on the library's navigation
 /// tools, and in particular see <doc:StackBasedNavigation> for information on modeling navigation
-/// using ``StackState`` for navigation stacks.
+/// using ``StackState`` for navigation stacks. Also see
+/// <doc:StackBasedNavigation#StackState-vs-NavigationPath> to understand how ``StackState``
+/// compares to SwiftUI's `NavigationPath` type.
 public struct StackState<Element> {
   var _dictionary: OrderedDictionary<StackElementID, Element>
   fileprivate var _mounted: Set<StackElementID> = []
@@ -78,19 +80,13 @@ public struct StackState<Element> {
 
 extension StackState: RandomAccessCollection, RangeReplaceableCollection {
   public var startIndex: Int { self._dictionary.keys.startIndex }
-
   public var endIndex: Int { self._dictionary.keys.endIndex }
-
   public func index(after i: Int) -> Int { self._dictionary.keys.index(after: i) }
-
   public func index(before i: Int) -> Int { self._dictionary.keys.index(before: i) }
-
   public subscript(position: Int) -> Element { self._dictionary.values[position] }
-
   public init() {
     self._dictionary = [:]
   }
-
   public mutating func replaceSubrange<C: Collection>(_ subrange: Range<Int>, with newElements: C)
   where C.Element == Element {
     for id in self.ids[subrange] {
@@ -210,7 +206,7 @@ extension ReducerProtocol {
   /// ergonomic and enforce correctness:
   ///
   ///   * It forces a specific order of operations for the child and parent features:
-  ///     * When a ``StackAction/element(id:action:)`` action is sent it runs runs the
+  ///     * When a ``StackAction/element(id:action:)`` action is sent it runs the
   ///       child first, and then the parent. If the order was reversed, then it would be possible
   ///       for the parent feature to `nil` out the child state, in which case the child feature
   ///       would not be able to react to that action. That can cause subtle bugs.