Inversion of Control: In Parent-Child relation, do I always need to declare the reducer for the child? How can I test the action that's handled by the parent reducer?

[bielikb]

Hi,

MeetingFooterView is a subview of the MeetingView.
MeetingFooterView supports one user action, that allows the user to skip the current speaker during the Scrum meeting.

enum MeetingFooterAction: Equatable {
    case skipSpeaker
}

In this relation, it's up to the parent - MeetingView to declare how this user action will be handled.

struct MeetingView: View {
    
    let store: Store...
    
    var body: some View {
        WithViewStore(store) { viewStore in
                ...
                    MeetingFooterView(store: store.scope(state: \.meetingFooterState,
                                                         action: MeetingAction.skipSpeaker))
                ...
        }
    }
}

You can see how I handle this single action here, in MeetingView source file.

In this case I didn't have to specify the environment nor the reducer for the MeetingFooterView.
The action itself doesn't mutate the MeetingFooterState, but the state declared by the parent.

Does it then make sense to actually test the MeetingFooterView itself? And could this inversion of control to be considered anti-pattern in some way?

As you can see in the code snippet below, I actually provided empty reducer and environment.

class MeetingFooterViewTests: XCTestCase {
    func testSkipAction() {
        let store = TestStore(initialState: MeetingFooterState(speakers: [ScrumTimer.Speaker(name: "John Doe", isCompleted: false)]),
                              reducer: Reducer<MeetingFooterState, MeetingFooterAction, Void>{ _, _, _ in .none },
                              environment: ())

        store.assert(
            .send(.skipSpeaker) { state in
                // No change to the `state` here
            }
        )
    }
}

Thanks for any thoughts on this!

Best,
Boris

PS:
Source code:
MeetingFooterView's implementation can be found here.

MeetingView's implementation can be found here.

[stephencelis]

Does it then make sense to actually test the MeetingFooterView itself?

I'd say so! The assertion that state doesn't change could be beneficial down the line. If the child ever changes its logic to do something internally, the test would begin to fail.

And could this inversion of control to be considered anti-pattern in some way?

Not at all! It's a pattern similar to the delegate pattern. The child provides delegate actions that a parent can listen to. In our projects we even like to group all delegate actions into a single case delegate 😄

[bielikb]

Oh, makes sense!
I'll add the test for this store to my repo.

Grouping all the delegate actions into a single case is actually pretty neat idea. I won't proceed with it within this specific project, but I'll keep it in mind when using TCA in other projects.

Thanks!

Best,
Boris