Swift UI API interface for SwiftCurrent

[Richard-Gist]

Upon working on the first implementation of SwiftUI with our AnyView wrapping inside a presenter, we ended up hitting a fair number of issues, that mostly stemmed from the way we interfaced with our Workflow. We decided to take a huge step back, and work through what kind of API we would want in a SwiftUI world.

For code snippets and where we're at right now, see the branch: swiftUI-again-spike and see the SampleView.swift file.

We currently have an API like this:

var workflow: Workflow = Workflow(FR1.self)
    .thenProceed(with: FR2.self)

var body: some View {
    SwiftUIResponder2(workflow: workflow) { _ in
    }
}

The above does not seem very SwiftUI-like and has been causing some issues with our sample apps as we have been implementing it.

var body: some View {
// Option 1
  SwiftUIResponder2(workflow: workflow) { _ in
  }.present(workflow)

// Option 2
  present(workflow)

// Option 3
  workflow.present()
}

The above were deemed rejected as they too did not feel like SwiftUI. Leaving us with the realization that the API for SwiftCurrent really does need to be seamless with the environment it is in. What we did for UIKit is not exactly what we will do for SwiftUI.

The closes we have gotten so far are these two options with more to come:

// Option 1
WorkflowGroup {
    FirstView() // but even if it takes parameters just use the () initializer
    SecondView()
        .background(shiftLeading ? .red : .blue)
        .transition(shiftLeading ? .slide : .fade)

    ...

    OneBeforeNthView()
        .show(when: .proceeding) //remove from stack when proceeding
    NthView()
        .show(when: .backingUp) //don't display unless backing up
}

// Option 2
WorkflowGroup {
    ThenPresent(FirstView())

    ReplaceWith(SecondView())
        .background(shiftLeading ? .red : .blue)
}

The first does not make it clear that each view will be shown sequentially, and the second is working through different options to make that clear.

At this point we have realized that we should open up this thought process to a Discussion topic. Mostly because this is a lot to put into an EOD on an issue, and second, because this issue is going to take quite a bit of deliberating on.

Ultimately we may end up where we started, but we should definitely take the time to make sure the experience as a Developer, is the experience we would all want.

[Richard-Gist]

Something we could take for inspiration on how to create many views is the LazyVStack:

LazyVStack(alignment: .center, spacing: nil, pinnedViews: [], content: {
    ForEach(1...10, id: \.self) { count in
        Text("Placeholder \(count)")
    }
})

It's something that takes in a few parameters and then creates numerous views, when needed.

[Tyler-Keith-Thompson]

My $0.02 don't have an initializer for things that take arguments...that doesn't take arguments. You'll break all kinds of compiler safety and Swift expectations. You can use types, and make those types accept view modifiers like other views do, or you can even wrap things to fit better:

FlowRepresentableView(FR1.self)
    .background(.red)

You can theoretically lose the fluent API in favor of a composable SwiftUI type API, but I wouldn't worry about peripheral words like thenPresent. I think a more friendly SwiftUI API is more like:

WorkflowView {
     WorkflowItem(FR1.self)
     WorkflowItem(FR2.self)
        .persistence(.removedAfterProceeding)
        .launchStyle(.modal(.fullScreen))
     WorkflowItem(FR3.self)
         .padding(10)
}.launchStyle(.navigationStack)

This also has a big advantage for other types of patterns, if you're a big believer in composable architecture's state exposure then you can easily do it using this method. Whereas with some of the others I see I feel like you give up a lot of flexibility and walk away some really unclear expectations of a thing that initializes but... doesn't?

[Tyler-Keith-Thompson]

Also while I'm on this brain train, this API might get you a lot closer to not even having an AnyView. Since you preserved all type information.

[Tyler-Keith-Thompson]

Ooh another thing: Instead of FlowRepresentable we could take our idea from UIKit and have:

WorkflowItem(FR1.self)

[Richard-Gist]

I'm liking this path better than in the start of the discussion. It allows for modifiers, uses the niceness for creating a view without calling a weird empty initializer, and helps with some of the clarity.

I still look at this and get a little confused on how many views are being presented. If we can make it apparent that we are going to display each view individually from top to bottom and not a cluster of views, I think this might be what I would want.

[Richard-Gist]

As we're currently discussing, here's another variant:

WorkflowView {
    Workflow(FR1.self)
        .thenProceed(with: FR2.self)
}

So View takes a closure that returns a Workflow

[Tyler-Keith-Thompson]

Update on this. @MattFreiburgAsynchrony and I spoke and quite like this as a possibility. We're going to spike it out next week to see how technically feasible it is. Perhaps there's space for both APIs. However, this in combination with something like #123 might feel a lot better to those familiar with SwiftUI.

[Richard-Gist]

A bit of details that didn't get documented above. We know what experience we want when it comes to the WorkflowGroup thing itself.

When you have a parent view (ContentView) and it has its own state and its own layout that changes on state, it should be able to update that as necessary WITHOUT impacting the state of the presented view. So if you were on FR3 and it had its own state of "input received", that state should be preserved, EVEN THOUGH ContentView relaid out. @wiemerm threw together a quick picture if people need a visual representation, but hopefully this is clear enough.

[Richard-Gist]

Starting a new thread for visibility. We had another riff on the latest suggestion:

WorkflowView {
    Workflow(WorkflowItem(FR1.self))
        .thenProceed(with: WorfklowItem(FR2.self).padding(10))
}

The thought being that because these are views we are swapping out, it will be really important to maintain the ability to modify the views. I will care A LOT about how my views are transitioning within a single page, unlike in UIKit where the paradigm is that the entire view is being replaced/covered.

[Tyler-Keith-Thompson]

I like that this re-uses the Workflow type that we've already established. Does this still play nice when you do a lot to each item?

WorkflowView {
    Workflow(WorkflowItem(FR1.self))
        .thenProceed(with: WorkflowItem(FR2.self)
                              .launchStyle(.modal)
                              .presentationType(.navigationStack)
                              .persistence(.removedAfterProceeding)
                              .padding(10)
                              .transition(.fade))
        .thenProceed(with: WorkflowItem(FR3.self)
}

[Richard-Gist]

Seems to play nice. What I'm not sure on is if it is a naming thing or what but there is a lot going on between the first 3 lines. I have 3 Workflow* things and I'm wondering how confusing that can get. It does logically break down to:

1. The view that you are placing on your screen
2. The sequence of views you want to show
3. The specific wrapper around the view being presented at this point.

[Tyler-Keith-Thompson]

Wanna sort of upvote this one again. I think this has the best of all worlds. It's very similar to what we already have, it keeps compiler safety between types, it uses modifiers to feel more SwiftUI like, meaning easy extensibility for us and others. The only drawback that I've really heard is that it has the word Workflow too many times, that's really easy to fix. You could remove the outermost layer (NOTE this is still different than all your other suggestions)

// One additional idea
WorkflowView(isPresented: $showWorkflow)
        .thenProceed(with: WorkflowItem(FR1.self))
        .thenProceed(with: WorkflowItem(FR2.self)
                              .launchStyle(.modal)
                              .presentationType(.navigationStack)
                              .persistence(.removedAfterProceeding)
                              .padding(10)
                              .transition(.fade))
        .thenProceed(with: WorkflowItem(FR3.self)
        .launchStyle(.modal) // launch style of WorkflowView, could be moved to the top, depends on consumer
        .onAbandon { 
            showWorkflow = false
        }

That's pretty easy. Then if you still feel over Workflowed you can change WorkflowItem to FlowRepresentable (although that's harder to type) or just about anything else you can come up with. The ultimate point is that names are easy to change, but this API is pretty solid for a lot of reasons.

Additionally I have a gut feeling that you'll be a lot closer to not having to use AnyView with this implementation. Short version? Your WorkflowItem is NOT specialized, it just holds onto a viewbuilder closure and uses that. That gives you all the benefits of SwiftUI AND gives you a type you can pass around to some responder to swap out at will.

[Richard-Gist]

I think this last one is my favorite so far. The way onAbandon is added, feels idiomatic for Swift. The chaining as you called out will allow us to extend and change the API easier without re-writing everything when we add a new closure (like onAbandon). The language holds similar to UIKit, making the transition to SwiftUI easier. And it fulfills all of the 6 scenarios listed that we wanted in an API.

[Richard-Gist]

As we discussed some of these options, where we are currently leaning is that a readable API is more important than for sure compile time safety in the data types of your items. One of the arguments being, that everyone will be impacted by the API and only some will be impacted by the compiler not flagging the data types as invalid in the flow. Additionally, we are not saying we couldn't, just that we are valuing readable API over compile time safety.

[Tyler-Keith-Thompson]

This makes sense provided that "Readability" doesn't expand to also mean "feels like". It is arguably a bad design choice to sacrifice safety for the express purpose of making it feel like other things. That's especially true if those other things are also unsafe.

In other words do you believe "feels like SwiftUI" > "Safe, and functional" or do you believe that "I can read, and understand what this does" > "Safe, and functional"?

[Richard-Gist]

I think the latter is what we are aiming for. For example:

WorkflowView { Workflow(WorkflowItem(FR1.self)) }

Is not very readable.

[wiemerm]

Some guiding thoughts I've had have been around we should focus on encouraging writing the cleanest code and not "gross" code. Defining that is still a bit hazy in making it more concrete, but I'm working through that. Some developers will take the extra step to extract things out to make it read more nicely and perhaps try to reduce the levels of indentation, etc. Others will just keep going with what's easier to write.

I'm leaning towards:

WorkflowView {
     WorkflowItem(FR1.self)
     WorkflowItem(FR2.self)
       .padding(10)
}

as it reads simply to know what items are in the workflow itself. Perhaps removing the View part of the WorkflowView name is part of reducing confusion.

[Richard-Gist]

Here are some scenarios we should be considering to verify the API we are leaning towards:

1. Able to apply view modifiers on a per view basis (especially transition animations).
2. Able to read the Workflow when there are many views present (at least 10).
3. Able to swap inline definition of views with a variable/property
4. Completion syntax makes sense when everything is inlined.
5. We have a way to abandon the Workflow.
6. We can set persistence and launch styles on a per view basis (most likely just another view modifier).

[wiemerm]

SwiftUIResponder2

Option 1

var body: some View {
  SwiftUIResponder2(workflow: workflow) { _ in
  }.present(workflow)
}

Pros

• Workflow is definied as a separate variable

Cons

• Writes us into a corner where we have to present the Workflow over top instead of inline or as part of a NavigationView
• It limites the flexibility of where a Workflow can be used

Option 2

var body: some View {
  present(workflow)
}

Presents itself as modular but is not in actuality

Option 3

var body: some View {
  workflow.present()
}

Cons

• Caused confusion

Applies to All Options

Pros

• If launching from more than one location - going to want that

Cons

• Not idiomatic to SwiftUI
• Not componetized/ not modular
• Don’t adapt to the new world of HOW something launches (present)

Captured Thoughts

• Extract the chain but not the view
• Completion blocks (in particular) will reference something in the hosting view

[wiemerm]

WorkflowGroup

Option 1

// Option 1
WorkflowGroup {
    FirstView() // but even if it takes parameters just use the () initializer
    SecondView()
        .background(shiftLeading ? .red : .blue)
        .transition(shiftLeading ? .slide : .fade)

    ...

    OneBeforeNthView()
        .show(when: .proceeding) //remove from stack when proceeding
    NthView()
        .show(when: .backingUp) //don't display unless backing up
}

Pros

• Felt more idiomatic than pure UIKit option

Cons

• Progression through the Workflow is unclear
  • Felt like presenting all of the items at once instead of one after the other
  • Is the top item first or is the bottom item first?

Option 2

// Option 2
WorkflowGroup {
    ThenPresent(FirstView())

    ReplaceWith(SecondView())
        .background(shiftLeading ? .red : .blue)
}

Pros

• Fixes the progression issue con of Option 1

All Options

Pros

• Modifiers on individual FlowRepresentables are clear

Cons

• Initializing FlowRepresentables when we shouldn't
• Initializers that don't exist
• Readability - not clear that FlowRepresentables take in a WorkflowInput or that the Workflow controls the data flow

[wiemerm]

WorkflowView

Tyler's

WorkflowView {
     WorkflowItem(FR1.self)
     WorkflowItem(FR2.self)
        .persistence(.removedAfterProceeding)
        .launchStyle(.modal(.fullScreen))
     WorkflowItem(FR3.self)
         .padding(10)
}.launchStyle(.navigationStack)

Pros

• Eliminates the false initializers
• ViewModifiers on individual FRs are clear
• Feels more idiomatic to SwiftUI - still not perfect

Cons

• Still lacks progression clarity
  • Felt like presenting all of the items at once not one after the other
  • Is top item first or bottom item first?
• Loses the ability to do compile time type safety for the parameters
  • Cannot guarantee that FR1 feeds into FR2 at compile time
  • Have we actually verified this assumption? What would it take to verify this or at least say it's too complex/difficult and therefore not worth it?

Alternate

WorkflowView {
     WorkflowItem<FR1>()
     WorkflowItem<FR2>()
        .persistence(.removedAfterProceeding)
        .launchStyle(.modal(.fullScreen))
     WorkflowItem<FR3>()
         .padding(10)
}.launchStyle(.navigationStack)

Comments

• The WorkflowItem<FR>() concept could replace any option where we've done WorkflowItem(FR.self)
• "Looks dope"

[wiemerm]

Enum

public enum FooView<Content>: View where Content : View {
   public var body: some View {
       switch self {
           default: EmptyView()
       }
   }

   init(@ViewBuilder content: () -> Content) {

   }

   case foo: Button = Button()
   case bar: Text = Text()

   func foo() { }
   var bar: Bool { true }
}


enum WorkflowViewy<Content>: View where Content : View { //    The view that you are placing on your screen
    case workflow                                        //    The sequence of views you want to show
    case workflowItems(Content)                          //    The specific wrapper around the view being presented at this point.

    init(@ViewBuilder content: () -> Content) {
        self = .workflowItems(content())
    }

    var body: some View {
        EmptyView()
    }
}


/*
WorkflowViewy {
    WorkflowViewy.init {
        SecondView()
            .padding()
            .foregroundColor(.blue)
            .transition(.slide)
    }
}
*/

Comments

• Ended up being a worse API and harder to implement than the implementation with

WorkflowView { 
   Workflow {
       WorkflowItem(FR1.self) 
       WorkflowItem(FR2.self) 
   }
} 

• Looks very similar to the button style with isPresented and completion action WorkflowView implementation
• “Doing it a worse way and a harder way for seemingly no benefit”

[wiemerm]

View Modifier/Presentation Route

VStack {
    Button("Launch!") {
        isPresented = true
    }
}.workflow(isPresented: $isPresented,
            launchStyle: .modal,
            transition: .slide) {
               WorkflowItem(FR1.self)
                    .padding()
                    .background(Color.blue)
            }

Comments

• Writes us into a corner where we have to present the Workflow over top instead of inline or as part of a NavigationView
• It limites the flexibility of where a Workflow can be used

[wiemerm]

Present FlowRepresentables as modifiers on WorkflowView

Option 1

var body: some View {
    WorkflowView()
        .thenPresent(FR1.self)
        .thenPresent(FR2.self)
}

Pros

• Simple, acceptable style
• Easy to read
• No need for View wrapping FR1.self
• This is what examples 2 or 3 would look like as default (no customization used)

Cons

• Too ambiguous in complicated situations
• Least defined

Option 2

var body: some View {
    WorkflowView(launchStyle: .inline)
        .thenPresent(FR1.self, launchStyle: .navigation)
        .thenPresent(FR2.self, modifiers: [.padding(16), .transition(.slide)])
}

Pros

• Transferrable with SwiftCurrent UIKit nomenclature
• It is very clear what modifiers or launchStyles go with which FRs
• More readable than 3
• Modifiers can be captured as a group and reapplied

Cons

• Doesn't feel like idiomatic SwiftUI
• Have to capture the whole WorkflowView in order to keep the chain

Option 3

var body: some View {
    WorkflowView()
        .launchStyle(.inline) 
        .thenPresent(FR1.self)
        .launchStyle(.navigation)
        .thenPresent(FR2.self)
        .padding()
        .transition(.slide)
        .background(Color.red)

    // As seen in the wild
    Text("1")
        .background(Image(systemName: "circle"))
        .frame(width: 200, height: 150)
        .background(Color.blue)
}

Pros

• Most idiomatic of the options - see the Text(“1”) in the example
• LaunchStyle and persistence become view modifiers, simplifying them from individual parameters and function calls
• Flexibility
• Still partially transferrable with SwiftCurrent UIKit (future state) - make Workflows have empty init and everything is in a thenPresent()

Cons

• Hard to read - especially with lots of items
• Even the Text example isn’t clear from reading what it actually looks like (needed to see on the canvas)
• Raises the barrier of entry of the library to highly experienced SwiftUI users
• Too flexible? How to restrict view types?
  • Do we want to?

Comments

Would we get a performance gain going this route?

[Tyler-Keith-Thompson]

You can have your cake and eat it to: #61 (reply in thread) captures the best parts of option 3, but helps reduce the noise by utilizing indentation.

[Richard-Gist]

Chosen direction

We have decided on an API to move forward with. Ultimately the API will look like this:

var body: some View {
    // example 1: Always presented, 2 item workflow, without arguments
    WorkflowView {
        WorkflowItem(FR1.self)
        WorkflowItem(FR2.self)
    }

    // example 2: Always presented, 2 item workflow, with arguments
    WorkflowView(launchingWith: "MY name is!") {
        WorkflowItem(FR1.self)
        WorkflowItem(FR2.self)
    }

    // example 3: Fully customized workflow with animation on abandon.
    WorkflowView(isLaunched: $isLaunched.animation(), launchingWith: "String in") {
        WorkflowItem(FR1.self)
        WorkflowItem(FR2.self)
            .presentationStyle(.modal)
            .persistence(.removedAfterProceeding)
            .applyModifiers {
                $0.background(Color.gray)
                    .transition(.slide)
                    .animation(.spring())
            }
    }
    .onAbandon { print("presentingWorkflowView is now false") }
    .onFinish { args in print("Finished 1: \(args)") }
    .onFinish { print("Finished 2: \($0)") }
    .background(Color.green)
    
    // example 4: Conditionally built workflow
    WorkflowView {
        WorkflowItem(FR1.self)
        if somePrecondition {
            WorkflowItem(FR2.self)
        }
        WorkflowItem(FR3.self)
    }

This API offers several benefits:

1. We feel it is idiomatic to SwiftUI and should feel natural to use
2. We limit the assumptions made for animating of the views while offering you the ability to still customize them as you please
3. When applying modifiers, $0 is typed as the underlying view, giving you the ability to use your custom modifiers that only apply to your types when setting up your views.
4. Type safety when declaring the WorkflowView as each proceed has type safety that the passed arguments align.

In addition to these benefits, we fulfilled the scenarios listed here.

1. Able to apply view modifiers on a per view basis (especially transition animations).
   • ACHIEVED: Using .applyModifiers
2. Able to read the Workflow when there are many views present (at least 10).
   • ACHIEVED: Indentations automatically applied by Xcode are legible.
     WorkflowGroup can be used to get more than 10 items
3. Able to swap inline definition of views with a variable/property.
   • ACHIEVED: WorkflowView can be captured in its own view or variable.
4. Completion syntax makes sense when everything is inlined.
   • ACHIEVED: onFinish is indented appropriately and can be placed anywhere in the start of the WorkflowView chain.
5. We have a way to abandon the Workflow.
   • ACHIEVED: We have exposed an abandon on workflow that can be called.
6. We can set persistence and launch styles on a per view basis (most likely just another view modifier).
   • ACHIEVED: They look like view modifiers that can be applied to a WorkflowView and WorkflowItem.

This is the direction we are heading. Not all modifiers will be implemented immediately nor will all names necessarily remain exactly this, but the general premise seems to be correct. If there are names that seem confusing or that you have suggestions to change to, please leave those as replies to this answer. Any and all feedback is welcome as well, so drop those in response to this answer as well.

[Richard-Gist]

This is no longer the case, as we have discovered while working on issue #101 and will be changing the API in #111

I will add another comment to this answer with the new discussion regarding that change when that discussion is created.

[Richard-Gist]

Discussion: Update to the SwiftUI API for the sake of NavigationLinks #113

[Tyler-Keith-Thompson]

Update on Richard's updates. The whole thing changed again because that's how incremental improvement works! I've edited his original answer with the current API. This one has afforded a lot of new benefits and is likely to stabilize.