Sharing (or synchronising) state in multiple navigation stacks

[technicated]

Hello everyone! First things first, thank you Point-Free team and all collaborators for the TCA library and all the great ecosystem that you have created!

I'm a PF subscriber and I have watched almost all episodes, and have tried TCA since its inception for small personal demo projects. I am not new to the ideas and concepts of the library, but I have what appears to be an app design question in mind.

The context is the following: I want to build a sample app to test TCA 1.0, and the app will show a list of movies and a list of actors, and then you can navigate to the detail (of one or the other), and then in the detail there is the name / title (of the actor or the movie) and a list of either the actors starring in the movie or the movies in with the actor has starred. You can continue to drill down as you wish by tapping on an item of these lists.

The screens are:

• a tab view, one tab is the list of all movies and one tab is the list of all actors (this is the root)
• list view: each row shows the name of the actor or movie, and there is a + button to add a new one
• detail view: has a toolbar title to show the name of the movie / actor, a section with a TextField to edit the name / title on the fly, and a section with the related movies / actors, from which one can navigate to another detail. There also is an add button to link a movie to the actor (or an actor to the movie, depending on which detail view we are talking about).

The act of linking a movie to an actor should be propagated to all existing detail views already on the stack and is also bidirectional i.e. all the presented detail of a movie should list the newly added actor, and all this actor's details should list the newly added movie. The toolbar title should also change to reflect this.

Hoping that the workings of the app is clear, the question is: what's the best way to model this (apparently?) bidirectional state and how to communicate the changes across all screens? Should I use a dependency and offer one or more "on change" endpoints to which each detail listens, or should I use delegate actions and communicate the changes from the detail to root, so that it can update all the detail views pushed on the stacks? Or a combination of both, or anything else? Thank you for you feedback! And if something's not clear ask and I'm going to clarify!

[mbrandonw]

Should I use a dependency and offer one or more "on change" endpoints to which each detail listens, or should I use delegate actions and communicate the changes from the detail to root, so that it can update all the detail views pushed on the stacks? Or a combination of both, or anything else? Thank you for you feedback! And if something's not clear ask and I'm going to clarify

Hi @technicated, I personally think the former pattern, where you model the movies/actors/… as a dependency is the way to go. Since this data must be ubiquitous throughout the application, is isn't much different from a database, user defaults, etc.

It's worth noting that in our Standups demo app we do not use this style, and instead use the latter pattern you described (that of delegate actions and feature communication to keep state in sync). However, this is only to keep things simple for a simple demo, but in reality it would be far better to model the persisted standups as a dependency.

[technicated]

Okay, so the core of the problem then becomes modelling that dependency correctly. I am thinking of something like the following:

struct Storage {
    var actors: () -> [Actor.ID: Actor]
    var actorChanges: (Actor.ID) -> AsyncStream<Actor>
    var upsertActor: (Actor) -> Void
    var actorLinks: (Actor.ID) -> AsyncStream<[Movie]>

    var movies: () -> [Movie.ID: Movie]
    var movieChanges: (Movie.ID) -> AsyncStream<Movie>
    var upsertMovie: (Movie) -> Void
    var moviesLinks: (Movie.ID) -> AsyncStream<[Actor]>

    var link: (Actor, Movie) -> Void
    var unlink: (Actor, Movie) -> Void
}

In this way, the Actor (Movie) detail view can listen for changes in the displayed Actor (Movie) links and update itself accordingly, like the following:

struct ActorDetailFeature: Reducer {
    struct State: Equatable {
        var actorId: Actor.ID
        var movies: [Movie] = []
    }

    enum Action {
        case task
        case updateMovies([Movie])
    }
  
    @Dependency(\.storage)
    var storage

    var body: some ReducerOf<Self> {
        Reduce { state, action in
            switch action {
            case .task:
                return .run { [actorId = state.actorId] send in
                    for await link in storage.actorLinks(actorId) {
                        let allMovies = storage.movies()
                        let actorMovies = link.compactMap { allMovies[$0.id] }
                        await send(.updateMovies(actorMovies))
                    }
                }

            case let .updateMovies(movies):
                state.movies = movies
                return .none
            }
        }
    }
}

However, this Storage interface seems really complex, and I haven't event accounted for the change of a Movie title (since this is not passing through the "links" concept, the Actor Detail UI won't update). How can I go about this dependency?

As a side note, in your opinion is this flow / interaction a simple one (talking about the entire demo app), a medium one, or an advanced / difficult one? I was thinking about medium, but I'm rapidly changing my mind!

Thank you for your support!

[technicated]

Sorry for the delayed response, but sometimes life just gets in the way!

I've posted some sample code for this problem and a stub of the solution at https://github.com/technicated/tca-state-sync/tree/main.

There's a README in there explaining how I tackled the solution, but the gist is that I restructured the Storage dependency and created Storage reducers inside the various lists / details Reducers to encapsulate and implement the sync logic.

Hope this helps! And I'd like to receive any feedback to see if there's an even better or different way to solve this!

Example of some code:

struct ActorDetailFeature: Reducer {
  struct State: Equatable { ... }

  enum Action: BindableAction {
    ...
    case storage(Storage.Action)
    ...
  }

  struct Storage: Reducer {
    enum Action {
      case actorChanged(ObjectChange<Actor>)
      case linksChanged(CollectionChange<Link>)
      case moviesChanged(CollectionChange<Movie>)
      case sync
    }

    @Dependency(\.storage)
    var storage

    var body: some Reducer<State, Action> {
      Reduce { state, action in
        switch action {
        ...

        case let .actorChanged(.initial(actor)),
             let .actorChanged(.inserted(actor)),
             let .actorChanged(.modified(actor)):
          state.actor = actor
          return .none

        case let .linksChanged(.changes(_, insertions, _, deletions)):
          let actorId = state.actor.id
          let movies = storage.movies.all()

          state.movies.append(
            contentsOf: insertions
              .filter { $0.actorId == actorId }
              .compactMap { movies[$0.movieId] }
          )

          deletions
            .filter { $0.actorId == actorId }
            .forEach { state.movies.remove(id: $0.movieId) }

          return .none

         ...

        case .sync:
          return .merge(                        
            .run { [actorId = state.actor.id] send in
              for await change in storage.actors.observeObject(actorId) {
                await send(.actorChanged(change))
              }
            },
            .run { send in
              for await change in storage.movies.observeAll() {
                await send(.moviesChanged(change))
              }
            },
            .run { send in
              for await change in storage.links.observeAll() {
                await send(.linksChanged(change))
              }
            }
          )
        }
      }
    }
  }

  @Dependency(\.storage)
  var storage

  var body: some ReducerOf<Self> {
    Storage()
    ... main feature reducer ...
  }
}

[mariob]

@technicated You should consider using GRDB (SQLite wrapper). I tried do all the syncing myself but I gave up and started to use GRDB.

GRDB is really nice layer on top of sqlite. It supports struct for persisted entities (which fits TCA state well) and you only need to confirm to protocols and still use plain model structs. If your structs are Codable you don't even have to do the "row-mapping", all is taken care of by GRDB. If you don't want disk persistence you can use in-memory db.

The Storage dependency is pretty easy to implement when using GRDB

[technicated]

Yeah, in a real project I wouldn’t probably roll my own solution for this, but this mini-project was a learning exercise so I decided to implement everything from scratch!