Removal of AnyView from SwiftUI implementation

[Tyler-Keith-Thompson]

Goals

• Remove all references to AnyView (started a branch called die-anyview-die
• Remove EmptyView as a necessity
• Get closer to how view swapping would work without SwiftCurrent (if you built it without the library you'd implement a model and a big switch block that swapped views)
• Remove launching from onLoad to a more appropriate place so that SwiftUI does not even try to render a view unless it's the correct view
• Test the hell out of it

Motivation

Apple has spoken before (most recently at WWDC2021) about how AnyView stops some of the SwiftUI optimizations they put in place. It can hinder animations and it generally gets in the way of performance. By removing our requirement for it we're getting a lot closer to a pure SwiftUI experience that follows best practices and acts very similarly to what a user would create without the library.

A note on SwiftUI:

Changing the state of a view while that view is rendering causes issues and is not a supported approach, for example:

struct WorkflowView<Content: View>: View {
    @Binding var isLaunched: Bool
    var body: some View {
        launcher()
    }
    
    func launcher() -> Content? {
        // launch workflow
        isLaunched = true // runtime error, not supported, BAD
        nil
    }
}

Design Approach

• Launch Workflow before the view renders, but also in a side-effect free way so that views getting initialized by SwiftUI at unpredictable times don't cause multiple launches
• Modify WorkflowViewModel so that it's published body is simply an Any?
• Steal the idea from ModifiedContent and make a ModfiedWorkflowView<Args, Wrapped: View, Content: View>
• When you first call thenProceed(with: WorkflowItem(FR1.self)) it returns a ModifiedWorkflowView<FR1.WorkflowInput, Never, FR1>
• When you next call thenProceed(with: WorkflowItem(FR2.self)) it returns ModifiedWorkflowView<FR2.WorkflowInput, ModifiedWorkflowView<FR1.WorkflowInput, Never, FR1>, FR2>
• When you finally call thenProceed(with: WorkflowItem(FR3.self).applyModifiers { $0.frame(width: 100) }) it creates a ModifiedWorkflowView<FR3.WorkflowInput, ModifiedWorkflowView<FR2.WorkflowInput, ModifiedWorkflowView<FR1.WorkflowInput, Never, FR1>, FR2>, ModifiedContent<_FrameLayout, FR3>>
• With all that juicy type information the magic can happen, each of the views essentially boils down to this:

struct ModifiedWorkflowView<Args, Wrapped: View, Content: View>: View {
    // model is here
    let wrapped: Wrapped?
    var body: some View {
        if let body = model.erasedBody as? Content {
            body
        } else {
            wrapped
        }
    }
    
    init(...) where Wrapped == Never {
        wrapped = nil
    }
    init<A, W, C>(workflowView: ModifiedWorkflowView<A, W, C>, ...) where Wrapped == ModifiedWorkflowView<A, W, C> {
        wrapped = workflowView
    }
}

• With that, we've got a series of views that cascade until it finds one that it can cast, then it displays. As model.body changes, the views update.

Things that went funny during the initial spike

• Originally I didn't have an else on the body (see example below) which worked fine unless a Workflow had 2 of the same item, then they both displayed

    var body: some View {
            model.erasedBody as? Content 
            wrapped
    }

• Finding out where to launch the Workflow was and continues to be a challenge. I've got some ideas that I'm still toying with that I'll describe elsewhere. Remember doing it in the onLoad is not preferable for a whole host of reasons, most of which are recursive...as in recursion is the problem AND as in solving part of the problem recurses and gets you more problems.

Affect on Public API

• None so far. I suppose I could solve some of my woes by adding a .launch() that told it expressly to get started by I'm working very hard to avoid that (possibly too hard?)

Affect on animations

• Suspected but not confirmed that animations will "just work™". This is because everything is inside an if statement, so you don't need to wrap if true around everything. I think the AnyView was actually causing weirdness there.

Potential Affect on Future Direction

• I like how this is shaping up, the "just do it like they would if the library was not around" approach should serve us well and avoid nasty surprises, even if it becomes particularly complicated on our end.
• It seems somewhat likely that this approach would lend itself well to modals and navigation stacks although I won't pontificate on how just yet
• As Apple makes changes to SwiftUI it seems likely this approach will allow us to keep up, since it's not doing anything too foreign.
• DOWNSIDE: Recursion is usually sort of hard to wrap your head around, it's no different here. It's challenging to think about how all this works, luckily we've got great tests.
• UPSIDE: It's easier with frameworks like ViewInspector because you don't have to trigger lifecycle events, that's quite nice.

Notes:

• I'll do my best to get small commits in place, ultimately there's a tipping point where there'll just be kind of a big one.
• I have not created an issue yet and would like to hold off, just in case this all blows up and dies horribly.

[Richard-Gist]

👏 👏 👏 Great post, @Tyler-Keith-Thompson . This is way more detailed than I was hoping for and every bit of it is appreciated.

Affect on Public API

• None so far. I suppose I could solve some of my woes by adding a .launch() that told it expressly to get started by I'm working very hard to avoid that (possibly too hard?)

I don't think you are working too hard to avoid it. I personally dislike the idea of adding a .launch() to our API and would strongly push to have it removed if you had submitted a PR with it.

I'll do my best to get small commits in place, ultimately there's a tipping point where there'll just be kind of a big one.

This is also fine. If things are not clear from the code and commits, we'll be sure to ask lots of questions in the PR.

[Tyler-Keith-Thompson]

K, I'm probably gonna start with a .launch() and get a working thing...then go through the process of trying to remove it.

[Richard-Gist]

Congrats, on getting rid of .launch(). It looks great!

[Richard-Gist]

Looks like you put this work into PR: #77