Dependency vs Part of State

[evilhonda3030]

Hey folks! I’m stuck trying to understand the mental model behind state and dependency modelling, especially I’m uncertain in how my reducers better gain access to the same data originally coming from external providers at the different levels in a parent-child state tree.

There are some certain scenarios I’m having issues to design.

Let’s say we have an app and many of its features are depending on the current user location. In the simplest scenario all of the app components especially if they are seen by users use the same most relevant instance of location.

2 ways to implement it:

1. As all of the features depend on the same location provider, there is no reason to have more than one effect in the system that is responsible for retrieving live user location. The result of this effect is the action which is received by the reducer at the very high level of the hierarchy.

   • What are my thoughts on the benefits of this approach?
     • The amount of actions received by the overall system is reduced as the only one effect employs location exists. However, most of the times location is just an input for another piece of state derived from the location. So most likely the location update will lead to some other effects to be launched and subsequently we will not have any “performance boost”
     • Location is in sync because it’s shared by the global state. This is also quite questionable because the location provider dependency might be implemented the way it provides the same data for all consumers

2. Implement LocationProvider dependency which can be then injected to any feature that needs an access to the location.

Final thoughts:

• Having location in the state looks very natural since it’s really the part of that is shared within all features.
• Most of the times it’s very difficult to bind child features to updates took place at the very difficult to bind leafs to updates took place higher in the hierarchy.

As for me I’ll prefer to deliver location to features via dependency but I’ll appreciate your input on my decision.

Is it bad? Do TCA has any manifesto on how to model your dependencies and where is the border between updatable property on state and dependency.

[simme]

Not sure if there's a right or wrong. But my mental model is that all "model" data should live in some form of dependency. Reducers that need this data all do their own observation/requesting of this data when they need it.

Sharing data between features using computed properties for child state or manually updating child state from a parent, or monitoring child state from a parent to update itself, is fraught with opportunities to miss propagating one property either way. Can also lead to state inconsistencies.

So all data that has a single source of truth lives in dependencies for me. Your LocationProvider can cache the location internally so that any actions sent as a result of a change are very light weight.

[simme]

Yeah, my interpretation is that it is the single source of truth for the "app state"/"view state". Not necessarily the entire app's data model. For my app that holds thousands of recipes that would mean I'd keep all of those in memory, which isn't feasible.

For small apps, sure, the TCA state can be the single source of truth for everything. But for larger apps you're going to have to break out some state into shared dependencies because passing the data around will become untenable and very hard to manage. Especially if you're also introducing sync or other means of changing the data from outside the TCA "world".

Say you have an app like Notes. You have a master view that shows a list of notes and a small preview, and then a detail view where the user can edit each note. A "naive" solution to this would be to load all notes into the apps memory upon launch. Then have the list view "share" a specific notes state with the detail view. If you put all of the app's state into TCA you'll end up with stuff like this:

struct Note: Identifiable {
  var id: UUID
  var note: String
}

struct ListsState {
  var notes: IdentifiedArrayOf<Note> = []
  var selectedNote: UUID?

  var detailState: DetailState? {
    get {
      guard let selectedNote, let note = notes[id: selectedNote] else { return nil }
    }
    set {
      if let newState = newValue {
        notes[id: newState.id] = newState.text
      } else {
        selectedNote = nil
      }
    }
  }
}

And now, what happens if you add sync to this? You'll need to hook up some database observation or sync engine at the root level or you app, and everytime you get a new value from the cloud you'll have to overwrite your app's state and have all of these computed properties propagate the change through the state hierarchy. But what if the user was making a change in a note that hadn't been synced yet? Now that's overwritten.

Trust me, I've been down this road with my shopping list app and it gets ugly and messy quickly :P Having TCA be the single source of truth for everything is not practical or desired. It also means that all of your features will be tightly coupled.

If all of the model data lived in a dependency your master view and detail view would not have to know about each other. They would each depend on some database client for observation and saving. This improves modularity, which is a core part of TCA imo.

---

It all depends on what you define to be your state. I design each feature/screen so that it's state contain what it needs to be rendered and do it's business logic in isolation. Sometimes I even defer business logic to a dependency.

For a small thing like just the user's location, sure you can have your root state fetch it and pass it around.

[simme]

And just to respond to this:

Currently I'm trying out something I found in another thread (can't remember where) - using mutable functions in the child feature's state to update the child state from the parent. The function may return an Effect if required. The parent called the function to update the child's state and the child may return an effects that needs to be executed, if required, because of the state change. Gives some structure to state sharing for things that needs to travel many levels.

Yes, that's also one way you can do it and manage the complexity somewhat. But you're still going to end up with explicit dependency on a child feature in a parent feature. Which may or may not be a problem. But for build time and previews it's not optimal (since you'll have to build your child dependencies just to preview your parent dependency).

There are multiple ways to do this. And I feel like the power of TCA is that there's not necessarily a right or wrong. This solution might be perfect in some cases! Pick and chose what fits best for your particular scenario. :) But don't disregard having dependencies as a source of truth for your data just because you feel like TCA should handle everything.

I would argue that in the case of location data the source of truth is specifically outside of the TCA realm because it comes from an external dependency (CoreLocation). So defining a client that you can mock to return different values in previews etc is very useful. Also since it's an async operation generally to fetch the location you'll want to be able to test/preview failures and delays.

Sure, if your child feature can only every be displayed once a location has been acquired by a parent feature, then by all means have it as a simple property on the child state that you pass during init.

[mariob]

@simme Hey! Thanks for the discussion.

After giving it some thought I've actually changed my mind regarding not storing state in dependencies. I'll probably refactor some parts of the application because it feels a bit awkward forcing the data to be shared as state in features. I have a similar situation as you with the shopping list. The in-memory thing is not a problem because we only allow max 200 items (for now) but I can see how this could quickly change in the feature and give head ache.

But for build time and previews it's not optimal (since you'll have to build your child dependencies just to preview your parent dependency).

But doesn't the parent module still need to do this anyway if you hold a child feature's state in the parent and use Scope/ifLets/etc?

[evilhonda3030]

Extremely sophisticated and useful example with notes syncing. But it feels more like an exception.

So the only thing that got more certain for is that there is no problem with sharing state via dependencies as I used to do it developing apps based on MV(X)

However, I do think computed properties have the application because if they are not, everything should be shared via dependencies

[akbashev]

@evilhonda3030

The problem is that TCA partially was introduced for os to deal with the single source of truth problem by introducing the state concept. Storing shared state in dependencies for me personally creates another one source of truth.

Think this is not what TCA introduced, state concept is common in functional programming. You basically model your app around one big state—which is whole world. In reality of course it's your CPU/GPU, peripherals and how they communicate with outside world.
If your phone changed location—it doesn't matter who subscribed to changes, but rather how you model your app around this calculation. So in the end Single state of truth vs. separate composable states are different only in the way how you propagate new information.
Though of course the latter can introduced new unwanted state in practice (some failure or delay).

[mbrandonw]

Shared state is tricky in TCA, but it's because TCA prefers features be built with value types and not reference types. In vanilla SwiftUI you can just pass around reference types all over the place to share state, but that also creates a very complex system that is hard to understand and difficult to test.

I will say that all of the new Observable stuff coming to iOS 17 does completely open all new doors for share state in TCA. We don't have any thing to share now, but it will be much easier to accomplish once we build the tools.

Going back to your concrete situation of needing location in many parts of an app, this definitely should be a dependency. The first style you mention doesn't work well because if you store the current location a single time in your state at the root of the application, there is no easy way to spread it throughout your other features. It requires complex use of computed properties to play changes back and forth between features, and it is easy to get wrong.

There was a lot of mention of "source of truth" in the dicsussions above, but that's a too simplistic way of looking at things. In reality, every application actually has two sources of truth, not one. There is the state that powers your view, such as every boolean that controls if something is enabled or not, etc. And then you have state that lives in external systems, such as the file system, user defaults, databases and on external servers. Every application has a mixture of both kinds of state, and both are very different.

The current location of the device is not view state. It's external state, and so belongs in a dependency. There are a few ways you can handle this, but here's one that comes to mind. You can model a location dependency like so:

struct LocationClient {
  var currentLocation: () -> Location?
  var trackLocation: () async -> Void
  var locationStream: () async -> AsyncStream<Location>
}

These 3 endpoints allow you to do the following:

• currentLocation is a synchronous endpoint for getting the location immediately. This allows you to grab the location right in the reducer and perform logic with it. No need to involve effects.
• The trackLocation can be called on app launch or once location permissions are granted, and it will start up the location manager under the hood in order to update the currentLocation data.
• And then for features that need to subscribe to the freshest location data, they can do so in an effect by invoking locationStream.

This allows you to share state across the entire type, and continue living in the value type world. Sure it may mean that each feature that needs location data has its own little copy of the current location in its state, and each feature may get actions delivered when the location changes, but that's not really that big of a deal.

[evilhonda3030]

Thanks!

I guess I've got another one example because the one with location seem obvious.

Imagine you've got an optional feature users can enable on different screens. Basically this is a flag which is stored in state and, of course, on disk for the restoration purpose.

This flag affects the appearance of multiple screens and, of course, when this flag is toggled on a certain screen, some other screens can be in navigation screen so they need to observe this change to align the UI with the most relevant state.

All is extremely easy when you need to just map this flag directly in the UI, let's say if the flag is on, the view background color red and if the flag is off, the background color is blue.

However, things are getting way more complicated when you need to do some additional work to make this flag affect the UI, let's say to load some data from the network. This, of course, can be done via OnChangeReducer at the higher level of the hierarchy but it's seems not as the viable solution as TCA really encourages you to think about your features locally.

Again we've got some inconveniences while trying to share the state.

What I understood through the discussion is that the state which doesn't require any effects to be processed before affecting the visual representation on the screen meaning it can be mapped to view state without any additional data should be shared via the app state.

Other things that require propagations up and down through the hierarchy to launch some effects are better to be shared via dependencies.

[akbashev]

to do some additional work to make this flag affect the UI, let's say to load some data from the network

If we're talking about mental model—toggling by user vs. fetching from network is not different though for the app, especially if you consider it could happen from any screen.

For me the rule is—if it changes frequently then it's better to encapsulate shared state and observe. If it happens rarely—global app state is fine.

[kdeda]

The current location of the device is not view state. It's external state, and so belongs in a dependency.

Bingo this was my question on the slack channel. Except for me the external state is a custom database.

[cdedagit]

I'm adopting the strategy on WebSocketActor: GlobalActor which is basically wrapping a shared state that helps the client provide the proper answers to independent reducers etc.

Many thanks at the guys from pf.

[akbashev]

Yep, same here. If there are some shared state required—I'm creating an actor with some simple observability pattern build on top of continuations.
Then whatever reducer can subscribe to state changes of this actor.