Structure Reducer

Printing is only done in debug (#if DEBUG) builds.

Printing is only done in debug (#if DEBUG) builds.

Printing is only done in debug (#if DEBUG) builds.

To use, build your app for Instruments (⌘I), create a blank instrument, and then use the "+" icon at top right to add the signpost instrument. Start recording your app (red button at top left) and then you should see timing information for every action sent to the store and every effect executed.

Effect instrumentation can be particularly useful for inspecting the lifecycle of long-living effects. For example, if you start an effect (e.g. a location manager) in onAppear and forget to tear down the effect in onDisappear, it will clearly show in Instruments that the effect never completed.

It is important to note that the order of combining reducers matter. Combining reducerA with reducerB is not necessarily the same as combining reducerB with reducerA.

This can become an issue when working with reducers that have overlapping domains. For example, if reducerA embeds the domain of reducerB and reacts to its actions or modifies its state, it can make a difference if reducerA chooses to modify reducerB's state before or after reducerB runs.

This is perhaps most easily seen when working with optional reducers, where the parent domain may listen to the child domain and nil out its state. If the parent reducer runs before the child reducer, then the child reducer will not be able to react to its own action.

Similar can be said for a forEach reducer. If the parent domain modifies the child collection by moving, removing, or modifying an element before the forEach reducer runs, the forEach reducer may perform its action against the wrong element, an element that no longer exists, or an element in an unexpected state.

Running a parent reducer before a child reducer can be considered an application logic error, and can produce assertion failures. So you should almost always combine reducers in order from child to parent domain.

Here is an example of how you should combine an optional reducer with a parent domain:

let parentReducer = Reducer<ParentState, ParentAction, ParentEnvironment>.combine(
  // Combined before parent so that it can react to `.dismiss` while state is non-`nil`.
  childReducer.optional().pullback(
    state: \.child,
    action: /ParentAction.child,
    environment: { $0.child }
  ),
  // Combined after child so that it can `nil` out child state upon `.child(.dismiss)`.
  Reducer { state, action, environment in
    switch action
    case .child(.dismiss):
      state.child = nil
      return .none
    ...
    }
  },
)

It is important to note that the order of combining reducers matter. Combining reducerA with reducerB is not necessarily the same as combining reducerB with reducerA.

This can become an issue when working with reducers that have overlapping domains. For example, if reducerA embeds the domain of reducerB and reacts to its actions or modifies its state, it can make a difference if reducerA chooses to modify reducerB's state before or after reducerB runs.

This is perhaps most easily seen when working with optional reducers, where the parent domain may listen to the child domain and nil out its state. If the parent reducer runs before the child reducer, then the child reducer will not be able to react to its own action.

Similar can be said for a forEach reducer. If the parent domain modifies the child collection by moving, removing, or modifying an element before the forEach reducer runs, the forEach reducer may perform its action against the wrong element, an element that no longer exists, or an element in an unexpected state.

Running a parent reducer before a child reducer can be considered an application logic error, and can produce assertion failures. So you should almost always combine reducers in order from child to parent domain.

Here is an example of how you should combine an optional reducer with a parent domain:

let parentReducer = Reducer<ParentState, ParentAction, ParentEnvironment>.combine(
  // Combined before parent so that it can react to `.dismiss` while state is non-`nil`.
  childReducer.optional().pullback(
    state: \.child,
    action: /ParentAction.child,
    environment: { $0.child }
  ),
  // Combined after child so that it can `nil` out child state upon `.child(.dismiss)`.
  Reducer { state, action, environment in
    switch action
    case .child(.dismiss):
      state.child = nil
      return .none
    ...
    }
  },
)

It is important to note that the order of combining reducers matter. Combining reducerA with reducerB is not necessarily the same as combining reducerB with reducerA.

This can become an issue when working with reducers that have overlapping domains. For example, if reducerA embeds the domain of reducerB and reacts to its actions or modifies its state, it can make a difference if reducerA chooses to modify reducerB's state before or after reducerB runs.

This is perhaps most easily seen when working with optional reducers, where the parent domain may listen to the child domain and nil out its state. If the parent reducer runs before the child reducer, then the child reducer will not be able to react to its own action.

Similar can be said for a forEach reducer. If the parent domain modifies the child collection by moving, removing, or modifying an element before the forEach reducer runs, the forEach reducer may perform its action against the wrong element, an element that no longer exists, or an element in an unexpected state.

Running a parent reducer before a child reducer can be considered an application logic error, and can produce assertion failures. So you should almost always combine reducers in order from child to parent domain.

Here is an example of how you should combine an optional reducer with a parent domain:

let parentReducer: Reducer<ParentState, ParentAction, ParentEnvironment> =
  // Run before parent so that it can react to `.dismiss` while state is non-`nil`.
  childReducer
    .optional()
    .pullback(
      state: \.child,
      action: /ParentAction.child,
      environment: { $0.child }
    )
    // Combined after child so that it can `nil` out child state upon `.child(.dismiss)`.
    .combined(
      with: Reducer { state, action, environment in
        switch action
        case .child(.dismiss):
          state.child = nil
          return .none
        ...
        }
      }
    )

• A writable key path that can get/set a piece of local state from the global state.

• A case path that can extract/embed a local action into a global action.

• A function that can transform the global environment into a local environment.

This operation is important for breaking down large reducers into small ones. When used with the combine operator you can define many reducers that work on small pieces of domain, and then pull them back and combine them into one big reducer that works on a large domain.

// Global domain that holds a local domain:
struct AppState { var settings: SettingsState, /* rest of state */ }
enum AppAction { case settings(SettingsAction), /* other actions */ }
struct AppEnvironment { var settings: SettingsEnvironment, /* rest of dependencies */ }

// A reducer that works on the local domain:
let settingsReducer = Reducer<SettingsState, SettingsAction, SettingsEnvironment> { ... }

// Pullback the settings reducer so that it works on all of the app domain:
let appReducer: Reducer<AppState, AppAction, AppEnvironment> = .combine(
  settingsReducer.pullback(
    state: \.settings,
    action: /AppAction.settings,
    environment: { $0.settings }
  ),

  /* other reducers */
)

Often used in tandem with pullback to transform a reducer on a non-optional local domain into a reducer that can be combined with a reducer on a global domain that contains some optional local domain:

// Global domain that holds an optional local domain:
struct AppState { var modal: ModalState? }
enum AppAction { case modal(ModalAction) }
struct AppEnvironment { var mainQueue: AnySchedulerOf<DispatchQueue> }

// A reducer that works on the non-optional local domain:
let modalReducer = Reducer<ModalState, ModalAction, ModalEnvironment { ... }

// Pullback the local modal reducer so that it works on all of the app domain:
let appReducer = Reducer<AppState, AppAction, AppEnvironment>.combine(
  modalReducer.optional().pullback(
    state: \.modal,
    action: /AppAction.modal,
    environment: { ModalEnvironment(mainQueue: $0.mainQueue) }
  ),
  Reducer { state, action, environment in
    ...
  }
)

Take care when combining optional reducers into parent domains, as order matters. Always combine optional reducers before parent reducers that can nil out the associated optional state.

• See also: IfLetStore, a SwiftUI helper for transforming a store on optional state into a store on non-optional state.

• See also: Store.ifLet, a UIKit helper for doing imperative work with a store on optional state.

// Global domain that holds a collection of local domains:
struct AppState { var todos: [Todo] }
enum AppAction { case todo(index: Int, action: TodoAction) }
struct AppEnvironment { var mainQueue: AnySchedulerOf<DispatchQueue> }

// A reducer that works on a local domain:
let todoReducer = Reducer<Todo, TodoAction, TodoEnvironment> { ... }

// Pullback the local todo reducer so that it works on all of the app domain:
let appReducer = Reducer<AppState, AppAction, AppEnvironment>.combine(
  todoReducer.forEach(
    state: \.todos,
    action: /AppAction.todo(index:action:),
    environment: { _ in TodoEnvironment() }
  ),
  Reducer { state, action, environment in
    ...
  }
)

Take care when combining forEach reducers into parent domains, as order matters. Always combine forEach reducers before parent reducers that can modify the collection.

// Global domain that holds a collection of local domains:
struct AppState { var todos: IdentifiedArrayOf<Todo> }
enum AppAction { case todo(id: Todo.ID, action: TodoAction) }
struct AppEnvironment { var mainQueue: AnySchedulerOf<DispatchQueue> }

// A reducer that works on a local domain:
let todoReducer = Reducer<Todo, TodoAction, TodoEnvironment> { ... }

// Pullback the local todo reducer so that it works on all of the app domain:
let appReducer = Reducer<AppState, AppAction, AppEnvironment>.combine(
  todoReducer.forEach(
    state: \.todos,
    action: /AppAction.todo(id:action:),
    environment: { _ in TodoEnvironment() }
  ),
  Reducer { state, action, environment in
    ...
  }
)

Take care when combining forEach reducers into parent domains, as order matters. Always combine forEach reducers before parent reducers that can modify the collection.

Take care when combining forEach reducers into parent domains, as order matters. Always combine forEach reducers before parent reducers that can modify the dictionary.