If there a limit on .ifLet reducer chaining?

[gkaimakas]

Hey everyone,

I have a pretty big reducer and it seems that if I chain a lot of ifLet reducers (over 4) the app crashes. The crash only happens on a device and cannot be replicated on a simulator.

I was able to circumvent the issue by chaining reducers to an EmptyReducer.

My original Reducer was:

        
        Reduce(_reduce(into:action:))
            .ifLet(
                \.onboardingState,
                 action: /Action.onboarding,
                 then: Onboarding.init
            )
            .ifLet(
                \.quoteOfTheDayState,
                 action: /Action.quoteOfTheDay,
                 then: QuoteOfTheDay.init
            )
            .ifLet(
                \.nutritionState,
                 action: /Action.nutrition,
                 then: Nutrition.init
            )
            .ifLet(
                \.mentalHealthState,
                 action: /Action.mentalHealth,
                 then: MentalHealth.init
            )
            .ifLet(
                \.surveyState,
                 action: /Action.survey,
                 then: Survey.init
            )
            .ifLet(
                \.communityNavState,
                 action: /Action.communityNav,
                 then: CommunityNav.init
            )
    }

The "fixed" reducer is this:

        Reduce(_reduce(into:action:))
            .ifLet(
                \.onboardingState,
                 action: /Action.onboarding,
                 then: Onboarding.init
            )
            .ifLet(
                \.quoteOfTheDayState,
                 action: /Action.quoteOfTheDay,
                 then: QuoteOfTheDay.init
            )
            .ifLet(
                \.nutritionState,
                 action: /Action.nutrition,
                 then: Nutrition.init
            )
            .ifLet(
                \.mentalHealthState,
                 action: /Action.mentalHealth,
                 then: MentalHealth.init
            )
        
        EmptyReducer()
            .ifLet(
                \.surveyState,
                 action: /Action.survey,
                 then: Survey.init
            )
            .ifLet(
                \.communityNavState,
                 action: /Action.communityNav,
                 then: CommunityNav.init
            )
    }

[mbrandonw]

Hi @gkaimakas, I'm not aware of any real limitation, but also it does not seem optimal to hold 6 optionals in state. That consists of 2^6 = 64 different states of being nil or non-nil. Are all of those states valid?

It seems more likely that only one of those values can be non-nil at a time, in which case an enum is better suited. You may be interested in our article on Tree-based navigation.

[stephencelis]

@kyleolson812 It's messy at the moment, but I did try a branch that removes one of the overloads. Can you point to remove-if-let-overload and see if that gets things compiling for you?

[kyleolson812]

@stephencelis I am afraid I cannot provide assistance with this. The code base that I am on is running a very old version of TCA.

[kyleolson812]

But to add more context to this, If I am using more than one .ifLet(). I will get a EXC_BAD_ACCESS error only on a physical device. Running a simulator works fine.

[AlessandroSteri]

@kyleolson812 this seems a stack overflow. The ___chkstk_darwin at the top of your stack suggests it has been detected. The reason why you have it on the device and not on the simulator is because the simulator has a much bigger stack size 😅 If you run it on release mode, the situation may improve (due to inlining).

What helped us to solve the issue 1. move pieces of state to the heap (including marking some enums with indirect) 2. try to reduce a bit the depth of the reducer chain (especially from the top where reducers operate on bigger states) 3. split huge switches (AFAIR, due to a bug big switches are stack-heavy).

[kyleolson812]

@AlessandroSteri Thank you for the insight on this! What we ended up doing as a temporary fix was to nest a "newer" reducer into an "older" reducer and use the .optional() modifier which in turn let me completely remove .ifLet. It seems to be working for now, but in an ideal world, the best answer would probably be to move to Tree-based navigation in the future. Again I want to reiterate that the codebase is large and we have an older version of the framework, so we are making do with what we have for now.

[dk-jlew]

If multiple of these need to be non-nil at the same time, it is possible to still use enum state, as @mbrandonw suggested, but contain them in a StackState as if you are using them in a SwiftUI NavigationStack (even if you aren't).

[mbrandonw]

If multiple of these need to be non-nil at the same time, it is possible to still use enum state, as @mbrandonw suggested, but contain them in a StackState as if you are using them in a SwiftUI NavigationStack (even if you aren't).

Hi @dk-jlew, this may be better suited for a new discussion since it doesn't really seem relevant to the original discussion. And if you do that, please provide more context. For example, how do you expect to use StackState if not in a NavigationStack?