Proposal: FlowRepresentableView

[Tyler-Keith-Thompson]

Motivation

I've been toying with this idea for about a month now and am finally ready to put it down on paper and let the discussions happen. I dislike that consumers in SwiftUI have to declare weak var _workflowPointer: AnyFlowRepresentable? so that we can tie into the workflow lifecycle. It's true we need space on a struct to be able to give access to the workflow property and to make proceedInWorkflow function, but it doesn't necessarily have to be on our consumer's view struct.

Ultimately the motivation is to get rid of the need for consumers to have to declare that variable.

The FlowRepresentableView

I propose the creation of a FlowRepresentableView that exposes a workflow property and a proceedInWorkflow closure. This would act almost exactly like ScrollViewReader, or GeometryReader. I could be convinced the name needs to be FlowRepresentableReader or WorkflowReader just to really drive the point home. Consumers would be able to specify their input and output types, receive arguments, and proceed in their workflows.

With no input or output

struct NoInputOrOutputView: View {
    var body: some View {
        FlowRepresentableView { proxy in // WorkflowInput == Never, WorkflowOutput == Never
            proxy.passedArguments // This property is compile-time inaccessible, since its type is Never
            proxy.workflow // optional AnyWorkflow reference, exactly the same as other flowRepresentables get today
            proxy.proceedInWorkflow() // call this to proceed
            try? proxy.backUpInWorkflow() // call this to back up
        }
    }
}

With Input of String

struct InputView: View {
    var body: some View {
        FlowRepresentableView(input: String.self) { proxy in // WorkflowInput == String, WorkflowOutput == Never
            proxy.passedArguments // This property is a string, do what you want with it.
            proxy.workflow // optional AnyWorkflow reference, exactly the same as other flowRepresentables get today
            proxy.proceedInWorkflow() // call this to proceed
            try? proxy.backUpInWorkflow() // call this to back up
        }
    }
}

With Input of String, Output of Int

struct InputAndOutputView: View {
    var body: some View {
        FlowRepresentableView(input: String.self, output: Int.self) { proxy in // WorkflowInput == String, WorkflowOutput == Never
            proxy.passedArguments // This property is a string, do what you want with it.
            proxy.workflow // optional AnyWorkflow reference, exactly the same as other flowRepresentables get today
            proxy.proceedInWorkflow(0) // call this to proceed, must provide an integer
            try? proxy.backUpInWorkflow() // call this to back up
        }
    }
}

Important

If the view body erases the type like the examples above we lose safety on thenProceed calls completely. We've already got a discussion that might make that true. If we want to take this proposal but keep all type safety on thenProceed it'd need to look like this:

struct InputAndOutputView: View {
    var body: FlowRepresentableView<String, Int> {
        FlowRepresentableView { proxy in // WorkflowInput == String, WorkflowOutput == Never
            proxy.passedArguments // This property is a string, do what you want with it.
            proxy.workflow // optional AnyWorkflow reference, exactly the same as other flowRepresentables get today
            proxy.proceedInWorkflow(0) // call this to proceed, must provide an integer
            try? proxy.backUpInWorkflow() // call this to back up
        }
    }
}

The drawback here is that FlowRepresentableView must be the first thing declared in your body. This is perhaps less invasive than a _workflowPointer on your struct.

NOTE: This is not a mutually exclusive concept with our current implementation. We should be able to support both approaches simultaneously with minimal maintenance overhead.

Advantages

• The obvious one, consumers no longer have to declare a property they will not directly use. It can reduce confusion.
• This feels much more like a SwiftUI approach.
• Behavior of this view when not embedded in a WorkflowLauncher can act exactly like ScrollViewReader when it is not embedded in a ScrollView.
• Depending on how much we care about sticking with type-safety this makes composing views much easier, you really just need FlowRepresentableView for the relevant parts of your view, not all of it.
• This means you could have views completely ignorant of the fact they're in a workflow at all. It opens up a new world of potential design patterns.

Disadvantages

• Because the passed argument is on the proxy, consumers cannot access it outside their view body unless they create a @State variable with some default value (nil, for example).
• (Very fixable). With the current proposal handling of shouldLoad is not clear.
• With extreme composability and limited scoping of FlowRepresentableView comes the downside of losing compiler safety and having to change our ideas of what thenProceed does.
• If you declare your top-most body as FlowRepresentableView you're pigeonholing consumers in regards to how they create their views.
• Implementation of this idea may cause us to create a partially fragile detection of whether environment objects are available. I feel we can mitigate this risk, but it's a possibility.

[morganzellers]

I like the aesthetic of this approach more than our current one, but I don't know if the gains are worth some of these disadvantages:

• With extreme composability and limited scoping of FlowRepresentableView comes the downside of losing compiler safety and having to change our ideas of what thenProceed does.
• Because the passed argument is on the proxy, consumers cannot access it outside their view body unless they create a @State variable with some default value (nil, for example).
• If you declare your top-most body as FlowRepresentableView you're pigeonholing consumers in regards to how they create their views.

[Tyler-Keith-Thompson]

And to be clear we lose type safety if we choose to lose type safety. We can keep it if we have consumers declare that as their body instead of some View. Or, we can lose it which is already being discussed elsewhere.

[Richard-Gist]

I'm not in love with it, but maybe that will change as I ask some questions.

1. What does this even look like when you are declaring a workflow? This seems to imply that any view could go into a WorkflowLauncher as long as it has a var body: FlowRepresentableView property? Or I suppose that would mean that a view with typealias Body = FlowRepresentable would be required in the WorkflowLauncher?
2. I'm not seeing a strong argument for how this is better than a _workflowPointer other than maybe the user not having to worry about making it weak?
3. My immediate thought was, I'm going to make 2 or stick it in a VStack or have a Text("Awesome title) above it and FlowRepresentableView below the Text or put a conditional around it. That seems to break this implementation but does not guide you to not being able to do it.

As I continue to process what it is really doing, I start to wonder how this makes your entire view behave with interacting with SwiftCurrent. It really seems like it is the thing that allows you to call proceed and backup and tell the workflow to abandon... which would incline me to sometimes only declare it at the point of use, and other times somewhere in the middle, but really they have to wrap everything in this and then when you want to call proceed, you need to call proxy.proceedInWorkflow().

So to visualize what I'm thinking this ends up being for consumers is:

struct FR1: View {
    var body: some View {
        FlowRepresentableView(output: String.self) { proxy in
            Button("Proceed in workflow") { proxy.proceedInWorkflow("Take me forward") }
        }
    }
}

struct FR2: View {
    var body: some View {
        FlowRepresentableView<String, Never> { proxy in
            Text(proxy.passedArguments)
            Button("Proceed in workflow") { proxy.proceedInWorkflow() }
        }
    }
}

struct Content: View {
    var body: some View {
        WorkflowLauncher(isLaunched: .constant(true)) {
            thenProceed(with: FR1.self) {
                thenProceed(with: FR2.self)
            }
        }
    }
}

And that's the required path to compile, not what I wanted to do while writing FR1/FR2.

[Tyler-Keith-Thompson]

To elaborate ScrollViewReader { proxy in } will render the thing, but any calls to proxy are just a no-op. If you are not embedded in a ScrollView

[Richard-Gist]

It'd have to, yeah. But exactly like ScrollViewReader it'd only function when you composed with FlowRepresentableView. So at least there is precedent for a Reader only working when it is embedded.

I feel like a Reader is unidirectional in its dependency. Reader only works when embedded, but the thing embedding it does not strictly care... In my head, the WorkflowLauncher is now at risk of breaking because you threw in a view that WAS using the view at one point, but now it is not. You only know there's a problem when you go to follow the workflow through.

I feel like there is some gain you could get from allowing any view into thenProceed, but I'm not there to that either. And I think that is a different conversation than removing type safety.

[morganzellers]

I do like the API of the one that gets rid of type safety more than the one that keeps it.

[Tyler-Keith-Thompson]

Hrm, I disagree with the premise that WorkflowLauncher is at risk of breaking. I still view it identically to ScrollViewReader. Here's my rationale, ScrollView embeds content in a view that can scroll WorkflowLauncher embeds content in a workflow that can proceed. The proxy enables control over when the scrolling happens, The proxy enables control over when the proceeding happens. It isn't broken, it's just that you need to call proceed.

It is an identical risk if someone uses our current approach, conforms to FlowRepresentable but simply never calls proceedInWorkflow

[Richard-Gist]

CHECKPOINT:

I like:

From working in FR1/2 point of view, I enjoy the easier syntax of declaring myself FlowRepresentable as a body. I can easily type my input and output right there in the body, and I don't even have to declare a weak var _ thing.

With thenProceed using Views and not FlowRepresentable, I like how FR2 can declare the proxy wherever I want to declare it.

Current feeling: Overall, I don't like it, and I'm not sure how to articulate why...

[Tyler-Keith-Thompson]

Things have changed and it makes this conversation worth revisiting. We no longer have compile-time safety on SwiftUI because the compiler simply couldn't handle it (see #112 for more info). Because of that my "second" proposed option is the only valid one anymore. @wwt/workflow-developers With that additional context, how do you feel about this proposal?