Compiler getting confused by different overloads of IfLetStore

[ghost]

Hello :)

In one of my scenes, I have a subview in the scene view that may or may not exist so its state is described by an optional property in the state that describes the scene's view. Note that this is not a presentation in the sense of Destination, @PresentationState, etc.

Naturally, I went for the use of IfLetStore but the compiler gets confused and thinks that I'm trying to use the overload that's applicable for the @PresentationState case. Or at least that's what I think is happening, because when I replace the IfLetStore with a "manual" implementation, everything builds fine.

The following doesn't compile (the compiler complains about not being able to type-check in a reasonable amount of time):

In State:

var mySubscene: MySubscene.State?

In Action:

case mySubscene(MySubscene.Action)

Somewhere inside the View's body:

IfLetStore(
    store.scope(
       state: \State.mySubscene,
       action: Action.mySubscene
    ),
    then: MySubscene.View.init
)

while this does:

WithViewStore(store, observe: \.mySubscene) { vs in
   if vs.state != nil {
      MySubscene.View(store: store.scope(
         state: { $0.mySubscene! }, 
         action: Action.mySubscene
      ))
   }
}

Has anyone else experienced this kind of behavior? Is there something I can do to nudge the compiler to recognise the overload I want to use?

Many thanks in advance.

[mbrandonw]

Hard to say without a reproducible sample project. Can you share one?

It may just be that the view is too complex for SwiftUI. Is it a big view?

[ghost]

Actually, I am now using an if let instead of the test against nil so I don't need to force-unwrap but I like your suggestion even better. Thanks!

[tgrapperon]

Using then: MySubScene.View.init) is also slightly harder on the compiler. I'd try using an explicit closure.

[ghost]

Here's another issue I just ran into. The same scene has several presentations in addition to that subview:

.sheet(
   store: store.scope(state: \.$destination, action: Action.destination),
   state: /Destination.State.scene1,
   action: Destination.Action.scene1,
   content: Scene1.View.init
)
.sheet(
   store: store.scope(state: \.$destination, action: Action.destination),
   state: /Destination.State.scene2,
   action: Destination.Action.scene2,
   content: Scene2.View.init
)
.sheet(
   store: store.scope(state: \.$destination, action: Action.destination),
   state: /Destination.State.scene3,
   action: Destination.Action.scene3,
   content: Scene3.View.init
)
.fullScreenCover(
    store: store.scope(state: \.$destination, action: Action.destination),
    state: /Destination.State.helpCenter,
    action: Destination.Action.helpCenter,
    content: { subStore in
       WithViewStore(subStore, observe: { $0 } ) { vs in
          CustomWebView(url: vs.state)
       }
    }
 )
.fullScreenCover(
    store: store.scope(state: \.$destination, action: Action.destination),
    state: /Destination.State.whatsNew,
    action: Destination.Action.whatsNew,
    content: { subStore in
       WithViewStore(subStore, observe: { $0 } ) { vs in
          CustomWebView(url: vs.state)
       }
    }
 )
.alert(
   store: store.scope(state: \.$destination, action: Action.destination),
   state: /Destination.State.errorAlert,
   action: Destination.Action.errorAlert
)

Commenting out one of the fullScreenCover or the other compiles fine, but having them both causes the compiler to choke and not be able to type-check the view. I think I'm going to have to break this view into smaller chunks.

[mbrandonw]

Yeah, that is a lot of chaining for a SwiftUI view. It's probably further exacerbated by the WithViewStore's inside the content closures. Does it compile if you move those out somewhere else?

[ghost]

Yeah, I just replaced a bunch of subviews of the main view with functions that return them and then it compiled fine.