Simple way to get input from a child view

[sillygoose]

New to TCA and Swift and have a couple of issues I have been unable to sort out as I convert my first big feature to TCA using the Case Studies as examples. Everything as gone well and I have one hurdle to get some input data from a sheet that has two text fields and an Add button which verifies the input and closes the sheet. To allow testing the rest of the code I just added two stubbed values so I could complete and test the feature.

Here is the sheet code:

                .sheet(
                    isPresented: viewStore.binding(
                        get: \.isAddVehicleSheetPresented,
                        send: VehicleSettings.Action.setAddVehicleSheet(isPresented:)
                    ),
                    onDismiss: {
                        let vin = "NOT_A_VIN"
                        let name = "Vehicle name"
                        viewStore.send(.addNewVehicle(vin: vin, name: name))
                    }
                ) {
                    AddVehicleView(store: addVehicleStore)
                }

The original code I had used Bindings to pass the state but

   AddVehicleView(vin: $vin, name: $name)

that seems weird now and even when I tried using TCA bindings I failed to get it compiled or make it work. I thought I could hold on to the ViewStore for AddVehicleView() but I could not figure a way access the state after the view closed as a WithViewStore() wrapper is needed to get into the store state or I am not in a View.

Any ideas out there to solve this? I have been staring at the SharedState example code as a model for doing this but it has so much extra complexity I an hoping for a simpler solution and haven't found any similar threads using the new ReducerProtocol. In the meantime I am going to write my first tests, which is why I chose TCA in the first place.🤓

[JackYoustra]

Shared state is really tough (see my posing of the problem here: #1445 and attempted solutions here #1445 (comment)). You're going to have to do some codegen for the optimal, no-repetition solution (any ancestor has to have as a generated property every descendant touching shared state). I haven't heard from the creators that there's nothing in the works, so for now I'm hoping someone comes up with a nicer solution and I'm instead just repeating state and using single-level generated properties to achieve the injection.

More concretely, a compromise between quality and brevity looks like the following:

public var user: User?
public var _home: Home.State
public var home: Home.State {
    get {
        var injectable = _home
        injectable.user = user
        return injectable
    } set {
        _home = newValue
        _home.user = user
    }
}

(and then for further nesting repeated inside Home.State for every nested state)

You're going to have duplication of the User struct, but they'll stay in sync so it should only lead to excessive object clutter and missed optimization, not actual correctness issues.

[Alex293]

I don't think you need shared state for this as the parent has access to the child state so when the dismiss action fire, before setting the child to nil you can use the child state to create you object.

[mbrandonw]

I agree with @Alex293, and don't think this requires "shared state" in the sense that the parent wants to share state with the child. The reverse, that of the child sharing state with the parent, is implicit due to the fact that parent features hold onto all of the state of the child.

The way you can handle your situation is to have an addButtonTapped action in your child feature:

struct AddVehicleFeature: ReducerProtocol {
  struct State { … }
  enum Action { 
    case addButtonTapped
    …
  }
  …
}

And the AddVehicleFeature doesn't need to handle the logic for that action. It just needs to the view to send it so that the parent can see it.

Then in the parent, you can listen for that action, and perform the validation and adding logic:

struct VehicleFeature: ReducerProtocol {
  struct State {
    var addVehicle: AddVehicleFeature.State
    var isAddVehicleSheetPresented = false
    …
  }
  enum Action {
    case addVehicle(AddVehicleFeature.Action)
    …
  }
  var body: some ReducerProtocol<State, Action> {
    Scope(state: \.addVehicle, action: /Action.addVehicle) {
      AddVehicleFeature()
    }
    Reduce { state, action in 
      switch action {
      case .addVehicle(.addButtonTapped):
        // Validate state.addVehicle and perform logic
      }
    }
  }
}

That's the rough idea at least. If you can share a complete code sample we may be able to provide more help.

Once you get the basics down there are a few extra directions you could go to strengthen this feature. First, instead of holding onto addVehicle state and an isPresented boolean inside the parent feature, you could just hold onto an optional addVehicle. That would make the sheet be driven off of the optionality of the state. We have some case studies that show how to do this.

Second, right now the validation logic lives in the parent feature, but maybe you want to it to be in the child, and then once the child validates it communicates back to the parent that it is OK to add the vehicle. This can be done with an ad-hoc pattern of "delegate actions", where the child sends an action to itself that the parent listens to and interprets. We have a bunch of examples of this in our isowords project, and @krzysztofzablocki wrote a blog post about this pattern

[sillygoose]

This gives somewhere to start, I'll be back as I study up on using Scope() and the other resources you linked to.

Just a comment on the validation logic, I have two validations to perform:

• the Add button the child is disabled until a valid Vehicle Identification Number is entered so it is impossible to a add a VIN that is not validated.
• I also need to check for duplicate VINs, for this I need to access the array of vehicles that is held in the parent so this checking was done in the parent reducer.

But I created trimmed versions of the two features so you won't see any of this code in any example code I post.

[JackYoustra]

Ah my bad, I thought you needed the bidirectionality because of the binding. Delegate should work fine here, Oops!

[sillygoose]

Tried some of the ideas, was able to find a way forward but not using parent/child state. While I have the child reducer cases in the parent reducer they are never called so obviously I am missing something. I reduced the code to a minimum so perhaps someone can point out a flaw in the code and get me on the right track. If not, I'll be downloading IsoWords and seeing how the delegate method is used.

Parent: VehicleFeature.swift

import ComposableArchitecture
import SwiftUI

struct VehicleFeature: ReducerProtocol {
    struct State: Equatable {
        var addVehicle: NewVehicle.State = NewVehicle.State()
        var isAddVehicleSheetPresented = false
        var vehicles: [Vehicle] = []
    }
    enum Action: Equatable {
        case addVehicle(NewVehicle.Action)
        case addNewVehicleButtonPressed
        case setAddVehicleSheet(isPresented: Bool)
    }
    var body: some ReducerProtocol<State, Action> {
        Scope(state: \.addVehicle, action: /Action.addVehicle) {
            NewVehicle()
        }
        Reduce { state, action in
            switch action {
            case .setAddVehicleSheet(isPresented: true):
                state.isAddVehicleSheetPresented = true
                return .none
            case .setAddVehicleSheet(isPresented: false):
                state.isAddVehicleSheetPresented = false
                return .none
            case .addNewVehicleButtonPressed:
                state.addVehicle = NewVehicle.State()
                return .none
            //### How do these cases get called from the child?
            case .addVehicle(.addButtonTapped):
                return .none
            case .addVehicle(.vinChanged(_)):
                return .none
            //###
            }
        }
    }
}

struct VehicleFeatureView: View {
    let store: StoreOf<VehicleFeature>
    var body: some View {
        WithViewStore(self.store, observe: { $0 }) { viewStore in
            NavigationStack {
                Form {
                    Section("Vehicles") {
                        Button(action: { viewStore.send(.setAddVehicleSheet(isPresented: true)) }) {
                            Text("Add new vehicle")
                        }
                    }
                }
                .sheet(
                    isPresented: viewStore.binding(
                        get: \.isAddVehicleSheetPresented,
                        send: VehicleFeature.Action.setAddVehicleSheet(isPresented:)
                    )
                ) {
                    NewVehicleView(store: Store(
                        initialState: NewVehicle.State(),
                        reducer: NewVehicle()
                    ))
                }
                .navigationTitle("Vehicle Feature")
            }
        }
    }
}

Child: NewVehicle.swift

import ComposableArchitecture
import SwiftUI

struct NewVehicle: ReducerProtocol {
    struct State: Equatable {
        var vin: String = ""
    }
    enum Action: Equatable {
        case vinChanged(String)
        case addButtonTapped
    }
    var body: some ReducerProtocol<State, Action> {
        Reduce { state, action in
            switch action {
            case let .vinChanged(vin):
                state.vin = vin
                return .none
            case .addButtonTapped:
                print(state.vin)
                return .none
            }
        }
    }
}

struct NewVehicleView: View {
    @Environment(\.dismiss) var dismiss
    let store: StoreOf<NewVehicle>
    var body: some View {
        WithViewStore(self.store, observe: { $0 }) { viewStore in
            Form {
                TextField(
                    "VIN",
                    text: viewStore.binding(get: \.vin, send: NewVehicle.Action.vinChanged)
                )
                Button("Add") {
                    viewStore.send(.addButtonTapped)
                    dismiss() //Used to close sheet
                }
            }
        }
    }
}

[robfeldmann]

I'm on mobile and it's early for me so I might be wrong 😄, but I think it's because you are dismissing the child too early.

Button("Add") {
  viewStore.send(.addButtonTapped)
  dismiss() //Used to close 🚫 
}

In this case the parent reducer should do the dismissing of the child from its .addButtonTapped action (by setting the presentation bool to false). So remove the dismiss() call here.

This way the parent will have a chance to respond to the action before the child scope is destroyed.

[mbrandonw]

Hi @sillygoose, I think @robfeldmann is correct in that it would probably be best to handle the dismissing logic in the reducer since then you could write a test for it, but there's another problem with your code.

When constructing the NewVehicleView you are creating a brand new store that is completely disconnected from the vehicle's store:

NewVehicleView(store: Store(
  initialState: NewVehicle.State(),
  reducer: NewVehicle()
))

Instead, you should derive a store for the "new vehicle" feature from the "vehicle" feature so that whenever an action is sent in the child feature the parent feature will see it.

You can do this like so:

NewVehicleView(
  store: self.store.scope(
    state: \.addVehicle, 
    action: VehicleFeature.Action.addVehicle
  )
)

Now when the child feature sends the .addButtonTapped action, the parent reducer can see it and react to it:

case .addVehicle(.addButtonTapped):
  // Perform validation logic
  if valid {
    // Add the vehicle to the array
    …
    // Dismiss the modal
    state.isAddVehicleSheetPresented = false
  } else {
    // Vehicle not valid, do something
    …
  }
  return .none

Here's a few additional tips to consider once you get things working and are comfortable with how TCA features are composed:

• I would suggest not using a plain array for the vehicles and instead use an IdentifiedArray. This will help prevent all kinds of bugs and is a better fit for ForEachStore. All of TCA's case studies and demo apps use identified arrays, so look there for more info.
• It is best to name actions after what the user is doing rather than what the reducer will do. So, instead of .setAddVehicleSheet you can do .addNewVehicleButtonTapped. This way the reducer can be free to perform any logic it wants without needing to express it all in the name of the action.
• Right now you are observing all state in your view store since you are doing observe: { $0 }. Consider transforming state into just the bare essentials that the view needs. We have an article about that topic.

Good luck!

[sillygoose]

Nailed it - thank you! Changed the store as suggested and it now works.

And I will follow up on the three suggestions. When I decided I needed an iOS app and I found that SwiftUI existed I knew I needed to learn it, then I found TCA and decided it would be a better solution than the traditional approaches. I did one feature in the original format and I have to say that the new ReducerProtocol makes everything much easier. I also have to pull CAN bus data from an EV and your parsing library made it easy and the code is so readable. And I hope the new Clocks series will be put in sampling of the CAN bus data.

I am a retired old programer that just wants to learn a new skill every year and my $18/month investment in your tutorials has been worth every penny.