How to combine stack-based navigation with forEach Reducer (IdentifiedArrayOf/IdentifiedActionOf)

[TC72]

I've built a system with a hierarchy of of DaysFeature, DayFeature and Note Feature.

At each level I'm using IdentifiedArrayOf and IdentifiedActionOf to embed the child in the parent

        var days: IdentifiedArrayOf<DayFeature.State> = []

        case days(IdentifiedActionOf<DayFeature>)

and this kind of forEach in the reducer:

        .forEach(\.days, action: \.days) {
            DayFeature()
        }

If I have a naive system that just displays the full hierarchy:

              ForEach(
                store.scope(state: \.days, action: \.days ),
                  id: \.state.id
              ) { dayStore in
                    DayView( store: dayStore)
               }

And I repeat the system at the day/note level then everything works. I can add a day, add notes to it and at the top level save the data to a json file and open it back up next time.

I then added navigation so it would show a list of days first, then choose the day to add and edit notes. When I add that code the parent no longer sees the state changes as they are now passed through the path.

              ForEach(
                store.scope(state: \.days, action: \.days ),
                  id: \.state.id
              ) { dayStore in
                        NavigationLink(state: DaysFeature.Path.State.editDay( dayStore.state )) {
                          ListView(day: dayStore.state) // simple view to display the day in the list
                        }
                  }

I posted about this and the new shared state was mentioned as a possible way to make this work without having to use delegates to signal to the parent to save state. I tried looking at the syncup example in the shared state beta but it doesn't use this style of hierarchy for parents and children. The syncupslist has an array of syncups, a normal swift struct not a feature, a separate syncup detail feature is then used to edit the feature and shared state can pass around a syncup struct with no problem.

I'm stuck with how I could use shared state with the structure I'm using. I can't work out how I'd use the $ notation for shared state in the foreach for the NavigationLinks.

I'm just wondering if I'm looking at this in the wrong way as this way of embedding parents and children seems like a standard way to do things in TCA, as demonstarated in the ToDos example.

[mbrandonw]

It seems that Path.State.editDay should hold onto some kind of EditDayFeature.State, and that both DayFeature.State and EditDayFeature.State would hold onto @Shared state.

If that were the case then that shared state could be passed along from the parent to the edit feature:

NavigationLink(
  state: DaysFeature.Path.State.editDay(
    EditDayFeature.State(
      someSharedState: dayStore.$someSharedState
    )
  )
)

But also it's hard to give much concrete advice because there just isn't enough code and context to really understand what is going on in your situation. A minimal project that demonstrates the problem you are having would be the best way to get help.

[TC72]

Thanks, I'll get a basic project setup to show.

[TC72]

I've uploaded a simple project with 2 targets.

TCA Basic which uses parent/child relationships for Days/Day/Notes
TCA Navigation which adds navigation to the basic app with links to edit individual days and notes

On both of these I've used ._printChanges() at the root so state changes are shown.
The basic version stores all changes at the top level, the navigation version doesn't.

I'm not trying to say there is any kind of bug with TCA, this is me not understanding how to use these tools correctly.

[TC72]

Thanks for the thorough explanation. I had tried to use the SyncUp example as a basis but got a bit lost as it got more involved.

I had struggled to get my code working when using SyncUps method of using models and the idea a feature HAS something and not IS something.

I'll go back and try again starting with the latest shared state version.

[TC72]

@mbrandonw

I've started moving over to using models like SyncUps, but I wanted to push back a bit.
The way I had things was based on the Todos and VoiceMemos examples.
They don't use types to hold onto their feature's data and can make use of the really elegant parts of TCA like the foreach reducer and foreach in the view. You've said I don't need them because my example is basic, but this is just a very basic project I put together to show my issue, my real project does a lot more.

SyncUps is difficult to follow as an example because you must use navigation to make things work.
I started simple and changed my Note to be a model and my day feature then uses this to hold the notes:

        var notes: IdentifiedArrayOf<Note> = []

But I'm now completely lost on how I can use that in my view without using the navigation code like SyncUps.
I've failed with any code that would try to scope inside a foreach loop on notes and the only thing which works is this which I know is wrong:

            ForEach(store.notes) { note in
                HStack {
                    Text("Note:")
                    NoteView(
                        store: Store(initialState: NoteFeature.State(note: note)) {
                            NoteFeature()
                        }
                    )
                }
            }

[TC72]

I had hoped there would be some way to give the navigation tools enough info that changes could be applied to the app's state.
So for example if I edited a note I would pass the id for the day and the note and because they're all using IdentifiedArrays I'd be able to access them from my DaysFeature.

Maybe giving the navigation the path based on ids then you wouldn't need to give it a store, it would be able to scope the store the destination view needs based on those ids. So they'd be using the real state data and not a copy.

Alternatively maybe children could hold on to a parentId and then it'd be possible to work back up to the top level.

[mbrandonw]

I've started moving over to using models like SyncUps, but I wanted to push back a bit.

There's nothing to push back on 🙂. I am merely describing how value types work in Swift, and they just do not do what you are trying to get them to do. You have two separate copies of DayFeature.State in your app. One is held in the days identified array and the other in the path stack state. Those copies of state are fully separated, and the only way to keep them in sync is by the parent listening for actions in the child in order to replay those changes to the other copies.

The way I had things was based on the Todos and VoiceMemos examples.

Not every case study is in the most pristine state. Both of those case studies were made a long time ago, dating back to 0.1.0 of the library 4 years ago. In all honesty, they should be refactored to have a proper standalone Todo and VoiceMemo data type rather than conflating that with the feature's domain. And the todo app should not use forEach because each row has no behavior. Voice memos should use forEach cause each row manages an audio player, and so that warrants the extra power afforded by forEach.

You've said I don't need them because my example is basic, but this is just a very basic project I put together to show my issue, my real project does a lot more.

Can you describe a bit more about what your real project does in each row? Is there actual behavior and side effects in the row? If you are not executing effects within the actual row, then the forEach isn't buying you much except for complexity.

I had hoped there would be some way to give the navigation tools enough info that changes could be applied to the app's state.

There is, and that's what the SyncUps app is demonstrating. Here is a gist that shows how to repeat the pattern in SyncUps to your app. It can be a bit ugly, but that is just the cost of dealing with value types.

And of course, like I said before, this gets massively cleaned up if you use the @Shared tool that is in beta right now. You can look at the SyncUps demo in the shared-state-beta branch to see how much things simplified. Basically all of the delegate actions for communicating between parent and child go away and the child features can just make mutations directly to its state and its automatically reflected in the parent.

[TC72]

@mbrandonw
Thanks for your patience in explaining this.

I took your gist and changed it to use @Shared, which was basically deleting a whole lot of code.
The path forward is now crystal clear.