Unsure how to use SwitchStore for an Enum State that is embedded within a conventional Struct State.

[james-rant]

Hi all,

I'm trying to use SwitchStore two conditionally show different views based on an activeFeature.

My set up is a Main Store (I guess equivalent to the App Store / State in the examples) with two other Features, each with their own states, reducers, actions etc.

The MainState has an enum:

enum FeatureState: Equatable {
	case featureOne(FeatureOneState)
	case featureTwo(FeatureTwoState)
}

and a corresponding var:
var activeFeature: FeatureState = .featureOne(FeatureOneState(label: ""))

I've added .pullback enhancements to the MainReducer to expose the stores for the feature wrapped in the enum.

The intention is to be able to switch the active feature using this var, and have the SwitchStore swap out the view when it happens.

I've hit a road block though, where Swift just produces the error:

Failed to produce diagnostic for expression; please submit a bug report (https://swift.org/contributing/#reporting-bugs) and include the project

Obviously something about my setup is incorrect, but I'm at a loss as to what it is.

I've included a self-contained example showing the issue, hopefully looking at the code itself may shed more light on the problem than my vague description above.

SwitchStoreTest.zip

[mbrandonw]

Hi @james-rantmedia,

the problem is that you are applying SwitchStore to a store that holds onto MainState, but MainState isn't the enum. Instead, FeatureState is the enum, which is nested inside MainState.

If you don't need this additional layer of nesting you could flatten it to just a single enum and then your code would work as-is. Or, if that's not right for your situation, you need to first .scope the store to focus on just the enum FeatureState, and then SwitchStore will work:

SwitchStore(store.scope(state: \.activeFeature)) {
  ...
}

Also, I just wanna mention that sending actions from a view's initializer is not doing to be a good idea in the long run. You should consider view initialization to be a process that can happen many, many times out of your control, and so it doesn't directly map to an actual lifecycle event, such as "appearing". It is usually better to tap into .onAppear { } in the view to initialize state for a domain.

BTW, the compiler error you were seeing has gotten a bit better in the newest Xcode beta:

Cannot convert value of type '() -> TupleView<(CaseLet<MainState.FeatureState, MainAction, FeatureOneState, FeatureOneAction, FeatureOneView>, CaseLet<MainState.FeatureState, MainAction, FeatureTwoState, FeatureTwoAction, FeatureTwoView>)>' to expected argument type '() -> TupleView<(CaseLet<MainState, MainAction, FeatureOneState, FeatureOneAction, FeatureOneView>, CaseLet<MainState, MainAction, FeatureTwoState, FeatureTwoAction, FeatureTwoView>)>'

That's a lot to take in, but at least you can see that in one part it is referring to MainState.FeatureState and in the other it is referring to MainState.

[james-rant]

Thank you! It was indeed the scoping that was the issue that I'd overlooked! As for sending the actions in init, I'm aware. In our actual codebase the .initialise actions are returned as side-effect actions from the reducer handling the action that switches the active feature. But thanks again!
(For some reason, I'm unable to mark this as answered -- the button does nothing when I click it (tried in Safari and Chrome...))