What's more important: compiler safety or long workflows? (SwiftUI)

[Tyler-Keith-Thompson]

As it stands now you can get 8 thenProceed calls without a noticeable penalty. At 9 calls you get a noticeable delay in compile-time and at 10 it just never happens.

Fundamentally this is because the compiler is having to do a lot of work to understand the type we're creating, it's no joke when it gets large.

Opaque types are actually designed to solve this problem. That's why so many things are some View in SwiftUI. Without opaque types SwiftUI wouldn't really work because the types would be too complex for the compiler to understand in a reasonable amount of time.

First Option

We keep things as they are, we enjoy the fact that thenProceed(with: will give you the right information if you start messing up types. It's noted as a limitation of the Swift compiler that you can't get bigger workflows in SwiftUI and we shrug it off.

Option 2:

We use our own opaque types. I've tested this out and proven that it allows for very large workflows (potentially infinite, I gave up before hitting an upper bound, but I was also partially hampered by our new API, so I only got to about 150 items).

The downside of this is that you're erasing necessary information to create the safety we like on thenProceed(with:. SO that brings us to the question:

The big question

Given this information what is more important to @wwt/workflow-developers? Would you rather be able to create arbitrarily large workflows, or have the somewhat pathetic limitation of 9 items but keep all our juicy type safety?

[morganzellers]

I'm thinking that a lot more potential users will be hurt by only allowing ~8 thenProceed calls than the number of users that would be hurt by not having the type safety, but that's just a gut feeling.

[Richard-Gist]

Is there something we can do to have disjointed Workflows so that the compiler has to determine subsets and then connections between workflows? I'm thinking Workflow A starts with Int ends with String and Workflow B starts with String and ends with Boolean and they are each 8 workflows long inside. Essentially: SchedulingWorkflowPart1 and SchedulingWorkflowPart2?

[Tyler-Keith-Thompson]

Not within the same DSL description of a Workflow. So you can't do

WorkflowLauncher(isPresented: .constant(true)).thenProceed(with: WorkflowItem(FR1.self)).joining(WorkflowLauncher(isPresented: .constant(true)).thenProceed(with: WorkflowItem(FR2.self))

You run into the exact same limitations we ran into that required us to change the public API for nav links.

HOWEVER You can have FR1 have a button that launches a workflow containing FR2...so:

struct FR1: View, FlowRepresentable {
    weak var _workflowItem: AnyFlowRepresentable?
    @State var presentingWorkflow = false
    var body: some View {
        if !presentingWorkflow {
            Button("Next") {
                 // instead of proceed
                 presentingWorkflow = true
            }
        } else {
            WorkflowLauncher(isLaunched: .constant(true))
                .thenProceed(with: WorkflowItem(FR2.self))
        }
    }
}

[Tyler-Keith-Thompson]

Unless joining basically creates a new view that has the contents of this one??? Imagine a world where:

struct JointWorkflowView<F, W, C, F1, W1, C1>: View {
    enum WorkflowShown { 
        case first
        case second
    }
    @State var firstWorkflow: WorkflowLauncherView<WorkflowItem<F, W, C>>
    @State var secondWorkflow: WorkflowLauncherView<WorkflowItem<F1, W1, C1>>
    @State var workflowShown = WorkflowShown.first
    
    var body: some View {
        switch workflowShown {
            case .first:
                firstWorkflow.onFinish { workflowShown = .second }
            case .second:
                secondWorkflow
        }
    }
}

[Tyler-Keith-Thompson]

Nav links will probably break at that barrier, as will modals, and all kinds of other things.

[Tyler-Keith-Thompson]

As we continue down this path and embrace the ideas of opaque types I discovered a new Swift compiler constraint. Turns out with our the Swift compiler only allows nesting up to 256 items. So with our new API opaque types may not even be strictly necessary

[Richard-Gist]

Ultimately we removed compile-time safety for the validity of the Workflow and opted for a run-time check whenever the workflow is created to ensure it is valid. This allows for workflows longer than 9 items long, and provides feedback on initialization (avoiding having to run through the entire workflow).