Oliver Foggin - tca

Using custom reducers to make shared data even easier with TCA

2024-01-02T00:00:00+00:00

You can jump straight into the code here: swift-composable-subscriber</a>.</p>

In my recent article, Shared data in a TCA app</a>, I detailed how to use dependencies to store shared data that can be subscribed to from anywhere in your app.</p>

This means that anywhere in your app a reducer can return a run</code> effect from its body, loop on the values from an AsyncStream</code>, and return some other action to deal with the updated values.</p>

case</span> .task</span>:</span></span>
  return</span> .</span>run</span> {</span> send </span>in</span></span>
    for await</span> value </span>in await</span> someDependency.</span>valueStream</span>() {</span></span>
      await</span> send</span>(</span>.</span>newValueReceived</span>(</span>value</span>))</span></span>
    }</span></span>
  }</span></span></code></pre>
This makes it really easy to subscribe to any stream of data in your app and even keeps your reducers in sync when the data is updated.</p>
I then received a question on Mastodon from Ben Lings:</p>

Great stuff! This pattern has been very useful in the app we are building. I've been considering how to encapsulate accessing this sort of dependency in a higher order reducer, to reduce the task-foreach-send boilerplate. Any thoughts on that?</p>
</blockquote>
View the original Mastodon post</a>.</p>
And I was thinking about this in the app I'm working on currently. There are a few reducers that rely on multiple streams of data. This very quickly started to flood the reducer body with these same lines over and over again. We needed a way to refactor this out to make it easier to maintain whilst still giving us the control that we have here.</p>
This is where a custom reducer can come in to help us.</p>
The problem we are trying to solve can be described as:</p>

When an Action</code> occurs</li>
We should subscribe to some AsyncStream</code></li>
And when it receives a new value we should run some other Action</code></li>
</ul>
We can create this by creating our own custom reducer.</p>
I created a SubscriberReducer</code> that is generic over:</p>

Parent: Reducer</code>, because it needs to know about the Action</code> and State</code> of the parent.</li>
TriggerAction</code>, a specific action that will be used to trigger the subscription.</li>
StreamElement</code>, the type of element that the AsyncStream</code> will yield.</li>
Value</code>, the type of the value that we want to handle. This allows us to provide a transform if necessary.</li>
</ul>
By doing this we can create several helper functions like:</p>
.</span>subscribe</span>(</span>to</span>:</span> myDependency.valueStream, </span>on</span>:</span> \.task, </span>with</span>:</span> \.newValueReceived</span>)</span></span></code></pre>
This takes the five lines above and reduces it to a single line. And it allows us to add multiple subscriptions very easily.</p>
If the AsyncStream</code> type matches the action then we can just do this:</p>
Reduce</span> {</span> state, action </span>in</span></span>
  // This is the regular reducer.</span></span>
}</span></span>
.</span>subscribe</span>(</span>to</span>:</span> myDependency.valueStream, </span>on</span>:</span> \.task, </span>with</span>:</span> \.newValueReceived</span>)</span></span></code></pre>
If the type of the AsyncStream</code> doesn't match the action then you can provide a simple transform:</p>
Reduce</span> {</span> state, action </span>in</span></span>
  // This is the regular reducer.</span></span>
}</span></span>
.</span>subscribe</span>(</span>to</span>:</span> myDependency.intStream, </span>on</span>:</span> \.task, </span>with</span>:</span> \.newStringReceived</span>) {</span> intValue </span>in</span></span>
  "</span>\(</span>intValue</span>)</span>"</span></span>
}</span></span></code></pre>
And even if we have more complex logic that we need to run, we can do that also:</p>
Reduce</span> {</span></span>
  // This is the regular reducer.</span></span>
}</span></span>
.</span>subscribe</span>(</span></span>
  to</span>:</span> myDependency.stream,</span></span>
  on</span>:</span> \.some.trigger.action</span></span>
) {</span> send, streamElement </span>in</span></span>
  await</span> send</span>(</span>.responseAction</span>)</span></span>
  await</span> otherDependency.</span>doSomethingElse</span>(</span>with</span>:</span> streamElement</span>)</span></span>
}</span></span></code></pre>
This has been great for us as it has allowed us to greatly simplify the code involved when we have multiple subscriptions firing off. And it makes it much easier to read also:</p>
Reduce</span> {</span> state, action </span>in</span></span>
  // This is the regular reducer.</span></span>
}</span></span>
.</span>subscribe</span>(</span>to</span>:</span> myDependency.userStream, </span>on</span>:</span> \.task, </span>with</span>:</span> \.newUserDataReceived</span>)</span></span>
.</span>subscribe</span>(</span>to</span>:</span> myDependency.chatStream, </span>on</span>:</span> \.task, </span>with</span>:</span> \.newChatMessageReceived</span>)</span></span>
.</span>subscribe</span>(</span>to</span>:</span> myDependency.reactionStream, </span>on</span>:</span> \.task, </span>with</span>:</span> \.newReactionReceived</span>) {</span></span>
  Reaction</span>(</span>payload</span>:</span> $0</span>)</span></span>
}</span></span></code></pre>
Custom reducers can really help shift a lot of the cognitive load of your app so that you don't have to worry about it at code time and it makes for easier reading and understanding too.</p>
What custom reducers have you been able to create to help you offload repetitive work and reduce cognitive load?</p>
I hope this has helped you. You can find my code and SPM package on GitHub: swift-composable-subscriber</a>.</p>



Leveraging custom Reducers to manage actions in your TCA app
2023-12-19T00:00:00+00:00
As your TCA app grows, each feature accumulates more and more actions that it has to manage.</p>
This could be UI actions, internal actions, child feature actions, delegate actions, etc.</p>
enum</span> Action</span> {</span></span>
  case</span> onAppear</span></span>
  case</span> task</span></span>
  case</span> buttonTapped</span></span>
  case</span> closeButtonTapped</span></span>
  case</span> downloadResponse</span>(</span>Result</span><</span>UserInfo</span>>)</span></span>
  case</span> userProfile</span>(</span>UserProfile.State</span>)</span></span>
  case</span> favourites</span>(</span>Favourites.State</span>)</span></span>
  case</span> dismissFeature</span></span>
}</span></span></code></pre>
After a while it becomes difficult to know which actions are which and we need a way to separate them. A widely used pattern is to create nested actions that hold onto only the actions relevant to it.</p>
enum</span> Action</span> {</span></span>
  case</span> view</span>(</span>ViewAction</span>)</span></span>
  case</span> internal</span>(</span>InternalAction</span>)</span></span>
  case</span> destination</span>(</span>PresentationAction</span><</span>Destination</span>>)</span></span>
  case</span> delegate</span>(</span>DelegateAction</span>)</span></span>
</span>
  enum</span> ViewAction</span> {</span></span>
    case</span> onAppear</span></span>
    case</span> task</span></span>
    case</span> buttonTapped</span></span>
    case</span> closeButtonTapped</span></span>
  }</span></span>
</span>
  enum</span> InternalAction</span> {</span></span>
    case</span> downloadResponse</span>(</span>Result</span><</span>UserInfo</span>>)</span></span>
  }</span></span>
</span>
  enum</span> Destination</span> {</span></span>
    case</span> userProfile</span>(</span>UserProfile.State</span>)</span></span>
    case</span> favourites</span>(</span>Favourites.State</span>)</span></span>
  }</span></span>
</span>
  enum</span> DelegateAction</span> {</span></span>
    case</span> dismissFeature</span></span>
  }</span></span>
}</span></span></code></pre>
This gives us nice separation of the actions, but it makes it more difficult to organise the reducer body.</p>
Reduce</span> {</span> state, action </span>in</span></span>
  switch</span> action </span>{</span></span>
  case</span> .view</span>(</span>.onAppear</span>)</span>: ...</span></span>
  case</span> .view</span>(</span>.task</span>)</span>: ...</span></span>
  case</span> .</span>internal</span>(</span>.downloadResponse</span>)</span>: ...</span></span>
  case</span> .</span>destination</span>(</span>.</span>presented</span>(</span>.userProfile</span>))</span>: ...</span></span>
  case</span> .delegate</span>: ...</span></span>
  case</span> .view</span>: ...</span></span>
  }</span></span>
}</span></span></code></pre>
It's very easy to get these in a muddle, lose exhaustivity, or duplicate logic unnecessarily.</p>
But there is a way to make this much easier for yourself.</p>
The Reducer</code> type can be a bit daunting when you begin looking into how it works, but a lot of the custom reducers provided by the TCA package use a similar pattern. By looking at that and duplicating what we see, we can begin to put together an idea of how we might improve the situation here.</p>
Wouldn't it be nice to create something that allowed us to spawn off a separate Reducer</code> just for a particular sub-action?</p>
Something like NestedAction(\.view)</code> that would give us a body in which we just have to deal with the ViewAction</code> actions without worrying about the others.</p>
At first this seems similar to what Scope</code> does, but in our case the problem is a bit more subtle. We're processing the ViewAction</code>, but then we want to return an Effect</code> that deals with the top-level Action</code> enum. If we don't do this then we wouldn't be able to do something like this from the view action reducer:</p>
return</span> .</span>send</span>(</span>.</span>delegate</span>(</span>.dismissFeature</span>))</span></span></code></pre>
Which is essential if we want our app to continue working. And also, we still want to be able to mutate the regular State</code> without having to scope it.</p>
So, we'll need something that is generic over State</code>, Action</code>, and ChildAction</code>, and provides a way to scope into the child action.</p>
This is what I came up with:</p>
// 1.</span></span>
@</span>Reducer</span></span>
public struct</span> NestedAction</span><</span>State</span>,</span> Action</span>,</span> ChildAction</span>> {</span></span>
  // 2.</span></span>
  @</span>usableFromInline</span></span>
  let</span> toChildAction: AnyCasePath</span><</span>Action, ChildAction</span>></span></span>
</span>
  // 3.</span></span>
  @</span>usableFromInline</span></span>
  let</span> toEffect:</span> (</span>inout</span> State, ChildAction</span>)</span> -></span> Effect</span><</span>Action</span>></span></span>
</span>
  @</span>inlinable</span></span>
  public init</span>(</span></span>
    _</span> toChildAction</span>: CaseKeyPath</span><</span>Action, ChildAction</span>></span>,</span></span>
    toEffect</span>: </span>@</span>escaping</span> (</span>inout</span> State, ChildAction</span>)</span> -></span> Effect</span><</span>Action</span>></span></span>
  ) {</span></span>
    self.toChildAction</span> =</span> AnyCasePath</span>(</span>toChildAction</span>)</span></span>
    self.toEffect</span> =</span> toEffect</span></span>
  }</span></span>
</span>
  public func</span> reduce</span>(</span>into</span> state</span>: </span>inout</span> State, </span>action</span>: Action</span>)</span> -></span> Effect</span><</span>Action</span>> {</span></span>
    // 4.</span></span>
    guard let</span> childAction </span>=</span> self.toChildAction.</span>extract</span>(</span>from</span>:</span> action</span>)</span> else</span> {</span></span>
      return</span> .none</span></span>
    }</span></span>
</span>
    // 5.</span></span>
    return</span> toEffect</span>(</span>&</span>state, childAction</span>)</span></span>
  }</span></span>
}</span></span></code></pre>
Let's unwrap what it's doing:</p>

We define our NestedAction</code> reducer and make it generic over State</code>, Action</code>, and ChildAction</code>.</li>
We have a property of a case path which tells us how to get from an Action</code> to the relevant ChildAction</code>.</li>
Finally, we have a closure which takes in State</code> and ChildAction</code> and returns an Effect<Action></code>. This is the subtle difference between this and the Reduce</code> reducer, as that will have a function from State</code>, Action</code> to Effect<Action></code>.</li>
In the body of our NestedAction</code> reducer we first check to see if the action coming in is one that we're interested in. We do this by trying to extract the ChildAction</code> from the Action</code> using the case path. If that doesn't work then we're not interested, so we just return a .none</code> effect.</li>
If the child action can be extracted then we pass it and the state into the closure and return any Effect</code> that comes from that.</li>
</ol>
Now that we've created our new reducer, let's put it into use.</p>
Let's deal with the view actions:</p>
// We create a new NestedAction reducer just for the view action.</span></span>
NestedAction</span>(</span>\.view</span>) {</span> state, action </span>in</span></span>
  switch</span> action </span>{</span></span>
  case</span> .onAppear</span>:</span></span>
    state.text</span> =</span> "Hello, user!"</span></span>
    return</span> .none</span></span>
</span>
  case</span> .task</span>:</span></span>
    return</span> .none</span></span>
</span>
  case</span> .buttonTapped</span>:</span></span>
    return</span> .</span>run</span> {</span> send </span>in</span></span>
      let</span> userInfoResult </span>=</span> await</span> clientDependency.</span>downloadUserInfo</span>()</span></span>
      await</span> send</span>(</span>.</span>internal</span>(</span>.</span>downloadResponse</span>(</span>userInfoResult</span>)))</span></span>
    }</span></span>
</span>
  case</span> .closeButtonTapped</span>:</span></span>
    return</span> .</span>send</span>(</span>.</span>delegate</span>(</span>.dismissFeature</span>))</span></span>
  }</span></span>
}</span></span></code></pre>
For the other actions you can create separate NestedAction</code> reducers to deal with them. The body of the reducer will look something like this. And using Xcode's folding ribbon it literally looks just like this:</p>
var</span> body:</span> some</span> ReducerOf</span><</span>Self</span>> {</span></span>
  NestedAction</span>(</span>\.view</span>) {</span> ...</span> }</span></span>
</span>
  NestedAction</span>(</span>\.internal</span>) {</span> ...</span> }</span></span>
</span>
  NestedAction</span>(</span>\.delegate</span>) {</span> ...</span> }</span></span>
</span>
  NestedAction</span>(</span>\.destination</span>) {</span> ...</span> }</span></span>
}</span></span></code></pre>
Using this we could potentially mutate state in any of these reducers, but we still might want to use ifLet</code> reducers or onChange</code> reducers to add onto these. Especially with the onChange</code> reducer, we don't know where a particular property might change, so which reducer do we add it to?</p>
Thankfully TCA provides us with CombineReducers</code> for free, which we can make use of here. So, adding an onChange</code> reducer to the above might look like this:</p>
var</span> body:</span> some</span> ReducerOf</span><</span>Self</span>> {</span></span>
  CombineReducers</span> {</span></span>
    NestedAction</span>(</span>\.view</span>) {</span> ...</span> }</span></span>
</span>
    NestedAction</span>(</span>\.internal</span>) {</span> ...</span> }</span></span>
</span>
    NestedAction</span>(</span>\.delegate</span>) {</span> ...</span> }</span></span>
</span>
    NestedAction</span>(</span>\.destination</span>) {</span> ...</span> }</span></span>
  }</span></span>
  .</span>onChange</span>(</span>of</span>:</span> \.text</span>) {</span> oldValue, newValue </span>in</span> ...</span> }</span></span>
  .</span>ifLet</span>(</span>...</span>) {</span> ...</span> }</span></span>
}</span></span></code></pre>
This makes sure that wherever state is changed it will be caught in the onChange</code> reducer. Similarly, it makes sure that the ifLet</code> reducer is run before any of ours so that we can't invalidate the state in a way that breaks the app.</p>
Reducers are really powerful in TCA, and by taking common problems and wrapping the logic into a new Reducer</code>, we can really improve the look of our code and make it much more pleasurable to work with and maintain.</p>
What new reducers have you created in your own TCA projects? I'd love to hear about them.</p>


Managing Analytics in a TCA app
2023-12-14T00:00:00+00:00
One of the core requirements of any enterprise app is analytics. It's essential if the company wants to know how their app is used, how they can improve it, and ultimately how they can maximise its profitability.</p>
Integrating analytics into an app can be fairly easy using one of the many services that provide a way to log analytics with nice dashboards. Adding events to button presses, download results, or screen views can be very easy to do, but it can also take over the app and become invasive.</p>
You can very quickly get into a state where the analytics in the app start to crowd the actual features of the app. Consistency doesn't exist as there are no real rules as to where the analytics should be done. And testing analytics becomes difficult when they are reported from button presses or scroll events in the view.</p>
With TCA we have a well defined place to put all the logic of our apps: in the Action</code> of the Reducer</code>s.</p>
Can we exploit this to make analytics just as well defined without also flooding the feature code?</p>
My initial thought for analytics with TCA was to create a dependency that we can use to push our analytics through. In the reducer it looked something like this:</p>
var</span> body: ReducerOf</span><</span>Self</span>> {</span></span>
  Reduce</span> {</span> state, action </span>in</span></span>
    switch</span> action </span>{</span></span>
    case</span> .buttonTapped</span>:</span></span>
      state.message</span> =</span> "Button tapped!"</span></span>
      return</span> .</span>merge</span>(</span></span>
        .</span>run</span> {</span> _</span> in</span></span>
          await</span> analyticsClient.</span>send</span>(</span>"ButtonTapped"</span>)</span></span>
        }</span>,</span></span>
        downloadEffect</span></span>
      )</span></span>
    }</span></span>
  }</span></span>
}</span></span></code></pre>
This works, but it doesn't solve the problems. The feature code of the app quickly gets overrun with analytics. In the example above the buttonTapped</code> action is really there to start a downloadEffect</code>, but it has to be merged with the analytics, making it harder to see what the app is actually doing.</p>
It gets messy.</p>
By leveraging the composability of TCA reducers, and creating our own reducer, we can create a much more elegant way of sending analytics that is just as powerful, but confined to its own dedicated space away from the feature code.</p>
If you want to jump ahead and just get the code, I have created an SPM package that you can use: swift-composable-analytics</a>.</p>
The core idea of this method is to still use a dependency to send analytics through, but to create a way to access that dependency through a dedicated reducer that does nothing other than send analytics. It means that the analytics code still remains close to the feature code, but just far enough away to not flood the feature code.</p>
The end goal looks like this:</p>
var</span> body:</span> some</span> ReducerOf</span><</span>Self</span>> {</span></span>
  // 1.</span></span>
  AnalyticsReducer</span> {</span> state, action </span>in</span></span>
    // 2.</span></span>
    switch</span> action </span>{</span></span>
    case</span> .buttonTapped</span>:</span></span>
      // 3.</span></span>
      return</span> .</span>event</span>(</span>name</span>:</span> "ButtonTapped"</span>)</span></span>
    }</span></span>
  }</span></span>
</span>
  Reduce</span> {</span> state, action </span>in</span></span>
    switch</span> action </span>{</span></span>
    case</span> .buttonTapped</span>:</span></span>
      state.message</span> =</span> "Button tapped!"</span></span>
      // 4.</span></span>
      return</span> downloadEffect</span></span>
    }</span></span>
  }</span></span>
}</span></span></code></pre>

We have a new AnalyticsReducer</code> that gives us state and action just like any other reducer. But this time state is immutable. This means that our analytics code cannot affect the state of the app.</li>
We have access to all the actions defined in the reducer, so we can send analytics for any event that can happen in the app. Whether it is the user tapping a button, the results of a successful download, or an error received from a service we interact with.</li>
The AnalyticsReducer</code> function just returns AnalyticsData</code>, so it can't run any custom effects. It is completely isolated from the feature code.</li>
The feature code of the app is unaffected. We just treat the feature code as the standard feature code. In this case, the button just returns the downloadEffect</code> without needing to worry about analytics at all.</li>
</ol>
That's the plan, and all of this is done with a surprisingly small custom reducer:</p>
import</span> Foundation</span></span>
import</span> ComposableArchitecture</span></span>
</span>
public struct</span> AnalyticsReducer</span><</span>State</span>,</span> Action</span>>:</span> Reducer</span> {</span></span>
  @</span>usableFromInline</span></span>
  let</span> toAnalyticsData:</span> (</span>State, Action</span>)</span> -></span> AnalyticsData</span>?</span></span>
</span>
  @</span>usableFromInline</span></span>
  @</span>Dependency</span>(</span>\.analyticsClient</span>)</span> var</span> analyticsClient</span></span>
</span>
  @</span>inlinable</span></span>
  public init</span>(</span>_</span> toAnalyticsData</span>: </span>@</span>escaping</span> (</span>State, Action</span>)</span> -></span> AnalyticsData</span>?</span>) {</span></span>
    self.</span>init</span>(</span>toAnalyticsData</span>:</span> toAnalyticsData, </span>internal</span>: ())</span></span>
  }</span></span>
</span>
  @</span>usableFromInline</span></span>
  init</span>(</span>toAnalyticsData</span>: </span>@</span>escaping</span> (</span>State, Action</span>)</span> -></span> AnalyticsData</span>?</span>, </span>internal</span>: </span>Void</span>) {</span></span>
    self.toAnalyticsData</span> =</span> toAnalyticsData</span></span>
  }</span></span>
</span>
  @</span>inlinable</span></span>
  public func</span> reduce</span>(</span>into</span> state</span>: </span>inout</span> State, </span>action</span>: Action</span>)</span> -></span> Effect</span><</span>Action</span>> {</span></span>
    guard let</span> analyticsData </span>=</span> toAnalyticsData</span>(</span>state, action</span>)</span> else</span> {</span></span>
      return</span> .none</span></span>
    }</span></span>
</span>
    return</span> .</span>run</span> {</span> _</span> in</span></span>
      analyticsClient.</span>sendAnalytics</span>(</span>analyticsData</span>)</span></span>
    }</span></span>
  }</span></span>
}</span></span></code></pre>
This AnalyticsReducer</code> requires a function from (state, action) -> AnalyticsData?</code>, and everything else is done for you. If you return nil</code> from the function then nothing happens. Only when you return the AnalyticsData</code> does this access the analyticsClient</code> and send the data to our analytics services.</p>
Now we just need to create an AnalyticsClient</code> to use to send events for us. By default in my package I have created a .consoleLogger</code> analytics client that logs events out to the console. It looks like this:</p>
extension</span> AnalyticsClient</span> {</span></span>
  public static var</span> consoleLogger: Self</span> =</span> .</span>init</span>(</span></span>
    sendAnalytics</span>: {</span> analytics </span>in</span></span>
      print</span>(</span>"[Analytics] ✅ </span>\(</span>analytics</span>)</span>"</span>)</span></span>
    }</span></span>
  )</span></span>
}</span></span></code></pre>
It has a single function, sendAnalytics</code>, that takes the data and logs it to the console.</p>
To create our own AnalyticsClient</code> that sends events to our own service we just need to implement this sendAnalytics</code> function. Here is an example of a client that is written to send analytics to Firebase and Crashlytics:</p>
import</span> Firebase</span></span>
import</span> FirebaseCrashlytics</span></span>
</span>
public extension</span> AnalyticsClient</span> {</span></span>
  static var</span> firebaseClient: Self</span> {</span></span>
    return</span> .</span>init</span>(</span></span>
      sendAnalytics</span>: {</span> analyticsData </span>in</span></span>
        switch</span> analyticsData </span>{</span></span>
        case let</span> .</span>event</span>(</span>name</span>:</span> name, </span>properties</span>:</span> properties</span>)</span>:</span></span>
          Firebase.Analytics.</span>logEvent</span>(</span>name, </span>parameters</span>:</span> properties</span>)</span></span>
</span>
        case</span> .</span>userId</span>(</span>let</span> id</span>)</span>:</span></span>
          Firebase.Analytics.</span>setUserID</span>(</span>id</span>)</span></span>
          Crashlytics.</span>crashlytics</span>()</span>.</span>setUserID</span>(</span>id</span>)</span></span>
</span>
        case let</span> .</span>userProperty</span>(</span>name</span>:</span> name, </span>value</span>:</span> value</span>)</span>:</span></span>
          Firebase.Analytics.</span>setUserProperty</span>(</span>value, </span>forName</span>:</span> name</span>)</span></span>
</span>
        case</span> .</span>screen</span>(</span>name</span>:</span> let</span> name</span>)</span>:</span></span>
          Firebase.Analytics.</span>logEvent</span>(</span>AnalyticsEventScreenView, </span>parameters</span>:</span> [</span></span>
            AnalyticsParameterScreenName</span>:</span> name</span></span>
          ]</span>)</span></span>
</span>
        case</span> .error</span>(</span>let</span> error</span>)</span>:</span></span>
          Crashlytics.</span>crashlytics</span>()</span>.</span>record</span>(</span>error</span>:</span> error</span>)</span></span>
        }</span></span>
      }</span></span>
    )</span></span>
  }</span></span>
}</span></span></code></pre>
We extend AnalyticsClient</code> to provide a .firebaseClient</code>, and in the sendAnalytics</code> function we just inspect the data that comes in and send it to the relevant Firebase or Crashlytics service.</p>
To start using this we just need to inject the dependency when we create the root Store</code> of the app:</p>
let</span> rootStore </span>=</span> Store</span>(</span>RootReducer.</span>State</span>()) {</span></span>
  RootReducer</span>()</span></span>
}</span> withDependencies</span>: {</span></span>
  $0.analyticsClient</span> =</span> .</span>merge</span>(</span>.consoleLogger, .firebaseClient</span>)</span></span>
}</span></span></code></pre>
This is all we need now to start sending analytics from anywhere in the app, and we can use merge</code> to add multiple analytics services to our app.</p>
Finally we come to testing. Because all of the analytics of our app are sent via actions in a reducer it means that our tests have access to all of them.</p>
And we can provide a function to expect analytics data that is really powerful for testing. In our test we can tell the TestStore</code> that we expect to receive certain analytics data, and if we don't receive that the test will fail.</p>
func</span> testButtonTapped</span>()</span> async throws</span> {</span></span>
  let</span> store </span>=</span> TestStore</span>(</span>RootReducer.</span>State</span>()) {</span></span>
    RootReducer</span>()</span></span>
  }</span> withDependencies</span>: {</span></span>
    $0.analyticsClient.</span>expect</span>(</span>.</span>event</span>(</span>"ButtonTapped"</span>))</span></span>
  }</span></span>
</span>
  store.</span>send</span>(</span>.buttonTapped</span>)</span></span>
}</span></span></code></pre>
This test is exhaustive too.</p>
If you don't expect an event and then an event is sent, it will fail. If you expect an event and it doesn't get sent, it will fail. If the expected event is different from the sent event, it will fail.</p>
So the test really does cover every eventuality.</p>
I have found this to be a really effective way to manage and send analytics throughout the apps I've worked on. Adding a new analytics service is just a case of creating a new client and injecting it at the root. All of the analytics throughout the app then start getting sent to the new service.</p>
I hope this has given you a brief insight into how to leverage reducers and actions. This is only one use case I have created, but there are a lot more ways of extending TCA to provide benefits like this.</p>
You can get my SPM package swift-composable-analytics</a> on GitHub.</p>


Shared data in a TCA app
2023-12-13T00:00:00+00:00
A question that I come across a lot from people using TCA to help structure their apps is:</p>

How do you manage shared data in a large TCA app?</p>
</blockquote>
The initial thought process for many, myself included, is to somehow store shared data in the state of the root reducer and synchronise changes up and down the stack when it changes. So that children can make changes and it's updated back to the root. And then the root propagates these changes to all the children.</p>
This very quickly becomes hugely complicated and there is a much more elegant way using dependencies.</p>
Instead of using the root reducer to store our shared data we will create a dependency to store it for us. This dependency will expose an AsyncStream</code> of the type that we want to store. For a very basic example let's create a shared number that all parts of our app can access and update.</p>
Let's create our dependency:</p>
@</span>DependencyClient</span></span>
struct</span> NumberStore</span> {</span></span>
  var</span> value:</span> @</span>Sendable</span> ()</span> async</span> -></span> AsyncStream</span><</span>Int</span>></span></span>
  var</span> updateValue:</span> @</span>Sendable</span> (</span>Int</span>)</span> async</span> -></span> Void</span></span>
}</span></span></code></pre>
This is the signature of our dependency. It provides a way to get a stream of values that we should be able to subscribe to, and a way for us to update the current value.</p>
With this we can begin to imagine what our reducer will look like. It will need:</p>

State to hold onto the number</li>
The NumberStore</code> dependency</li>
An action to subscribe to the dependency</li>
An action to update the state</li>
</ul>
@</span>Reducer</span></span>
struct</span> SomeFeature</span> {</span></span>
  struct</span> State</span> {</span></span>
    var</span> number:</span> Int</span> =</span> 0</span></span>
  }</span></span>
</span>
  enum</span> Action</span> {</span></span>
    case</span> task</span> // the convention is to use the task name to mirror the view task</span></span>
    case</span> newNumberReceived</span>(</span>Int</span>)</span></span>
  }</span></span>
</span>
  @</span>Dependency</span>(</span>\.numberStore</span>)</span> var</span> numberStore</span></span>
</span>
  var</span> body:</span> some</span> ReducerOf</span><</span>Self</span>> {</span></span>
    Reduce</span> {</span> state, action </span>in</span></span>
      switch</span> action </span>{</span></span>
      case</span> .task</span>:</span></span>
        return</span> .</span>run</span> {</span> send </span>in</span></span>
          for await</span> value </span>in await</span> numberStore.value</span>() {</span></span>
            await</span> send</span>(</span>.</span>newNumberReceived</span>(</span>value</span>))</span></span>
          }</span></span>
        }</span></span>
</span>
      case</span> .</span>newNumberReceived</span>(</span>let</span> value</span>)</span>:</span></span>
        state.number</span> =</span> value</span></span>
        return</span> .none</span></span>
      }</span></span>
    }</span></span>
  }</span></span>
}</span></span></code></pre>
That's our basic reducer that subscribes to the updates. Now we need to implement the dependency.</p>
We'll first create a class to hold onto the value for us.</p>
class</span> NumberStorage</span> {</span></span>
  @</span>Published var</span> value:</span> Int</span> =</span> 0</span></span>
}</span></span></code></pre>
Then our dependency becomes very simple:</p>
extension</span> NumberStore</span> {</span></span>
  static var</span> liveValue: Self</span> {</span></span>
    let</span> storage </span>=</span> NumberStorage</span>()</span></span>
</span>
    return</span> .</span>init</span>(</span></span>
      value</span>: {</span></span>
        storage.$value</span></span>
          .streamValues</span></span>
      }</span>,</span></span>
      updateValue</span>: {</span></span>
        storage.value</span> =</span> $0</span></span>
      }</span></span>
    )</span></span>
  }</span></span>
}</span></span></code></pre>
Where we have defined streamValues</code> as an extension on Publisher</code>:</p>
public extension</span> Publisher</span> where</span> Self.Failure </span>==</span> Never</span> {</span></span>
  var</span> streamValues: AsyncStream</span><</span>Output</span>> {</span></span>
    AsyncStream</span>(</span>bufferingPolicy</span>:</span> .</span>bufferingNewest</span>(</span>5</span>)) {</span> continuation </span>in</span></span>
      let</span> cancellable </span>=</span> self.</span>sink</span> {</span> continuation.</span>yield</span>(</span>$0</span>) }</span></span>
      continuation.onTermination</span> =</span> {</span> _</span> in</span></span>
        cancellable.</span>cancel</span>()</span></span>
      }</span></span>
    }</span></span>
  }</span></span>
}</span></span></code></pre>
With all this in place any reducer in the app can now subscribe to a stream of values held by the NumberStore</code> dependency.</p>
Now that we've done that we could also create an action to update the value:</p>
case</span> updateValueButtonTapped</span>(</span>Int</span>)</span></span></code></pre>
And then handle it in the reducer:</p>
case</span> .</span>updateValueButtonTapped</span>(</span>let</span> value</span>)</span>:</span></span>
  return</span> .</span>run</span> {</span> _</span> in</span></span>
    await</span> numberStore.</span>updateValue</span>(</span>value</span>)</span></span>
  }</span></span></code></pre>
That's it for updating the value. This will trigger the update in the dependency which will then push the new value out to any reducers that are listening out for it.</p>
Finally we need to write the view to display the count.</p>
struct</span> NumberView</span>:</span> View</span> {</span></span>
  let</span> store: StoreOf</span><</span>SomeFeature</span>></span></span>
</span>
  var</span> body:</span> some</span> View </span>{</span></span>
    WithViewStore</span>(</span>store, </span>observe</span>: {</span> $0</span> }) {</span> viewStore </span>in</span></span>
      Text</span>(</span>"</span>\(</span>viewStore.number</span>)</span>"</span>)</span></span>
        .</span>task</span> {</span> await</span> store.</span>send</span>(</span>.task</span>)</span>.</span>finish</span>() }</span></span>
</span>
      Button</span> {</span></span>
        store.</span>send</span>(</span>.</span>updateValueButtonTapped</span>(</span>viewStore.number</span> +</span> 1</span>))</span></span>
      }</span> label</span>: {</span></span>
        Text</span>(</span>"Add one"</span>)</span></span>
      }</span></span>
    }</span></span>
  }</span></span>
}</span></span></code></pre>
The use of task</code> in the view will keep the subscription alive when the view is on screen and cancel it when the view disappears.</p>
So this is all that we need. This view will update the value displayed when any part of the app updates the value.</p>
Of course, this is only a very basic version and you may want to build in some security around race conditions, but this makes a lot of shared data very simple within a TCA app.</p>