Reducer

Initializes a reducer from a simple reducer function signature.

The reducer takes three arguments: state, action and environment. The state is inout so that you can make any changes to it directly inline. The reducer must return an effect, which typically would be constructed by using the dependencies inside the environment value. If no effect needs to be executed, a .none effect can be returned.

For example:

struct MyState { var count = 0, text = "" }
enum MyAction { case buttonTapped, textChanged(String) }
struct MyEnvironment { var analyticsClient: AnalyticsClient }

let myReducer = Reducer<MyState, MyAction, MyEnvironment> { state, action, environment in
  switch action {
  case .buttonTapped:
    state.count += 1
    return environment.analyticsClient.track("Button Tapped")

  case .textChanged(let text):
    state.text = text
    return .none
  }
}

A reducer that performs no state mutations and returns no effects.

Combines many reducers into a single one by running each one on state in order, and merging all of the effects.

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
    ...
    }
  },
)

Combines many reducers into a single one by running each one on state in order, and merging all of the effects.

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
    ...
    }
  },
)

Combines many reducers into a single one by running each one on state in order, and merging all of the effects.

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
        ...
        }
      }
    )

Transforms a reducer that works on local state, action and environment into one that works on global state, action and environment. It accomplishes this by providing 3 transformations to the method:

• 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 */ }
struct 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 */
)

Transforms a reducer that works on non-optional state into one that works on optional state by only running the non-optional reducer when state is non-nil.

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? }
struct 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.

A version of pullback that transforms a reducer that works on an element into one that works on a collection of elements.

// Global domain that holds a collection of local domains:
struct AppState { var todos: [Todo] }
struct 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.

A version of pullback that transforms a reducer that works on an element into one that works on an identified array of elements.

// Global domain that holds a collection of local domains:
struct AppState { var todos: IdentifiedArrayOf<Todo> }
struct 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.

A version of pullback that transforms a reducer that works on an element into one that works on a dictionary of element values.

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

Runs the reducer.

Undocumented

Prints debug messages describing all received actions and state mutations.

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

Prints debug messages describing all received actions.

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

Prints debug messages describing all received local actions and local state mutations.

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

Instruments the reducer with signposts. Each invocation of the reducer will be measured by an interval, and the lifecycle of its effects will be measured with interval and event signposts.

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.

Undocumented