Reimagining SwiftCurrent on SwiftUI #223
Unanswered
Tyler-Keith-Thompson
asked this question in
Ideas
Replies: 1 comment
-
I have a pretty reasonable prototype over on the reimagine-swiftui branch. These changes are feeling pretty great, but as of the time of writing there are unanswered questions and still missing functionality. Overview of the changes:Workflow Changes:
// old
WorkflowView {
WorkflowItem(Screen1.self) // not possible to extract :(
}
// new -- without extracting
WorkflowView {
WorkflowItem { Screen1() }
}
// new
WorkflowView {
workflow
}
@WorkflowBuilder var workflow: some Workflow { // extracted!
WorkflowItem { Screen1() }
}
// old
import SwiftCurrent
struct Screen1: View, FlowRepresentable {
weak var _workflowPointer: AnyFlowRepresentable?
var body: some View {
VStack {
Text("Hello, World!")
}
}
func shouldLoad() -> Bool {
true
}
}
// new
import SwiftCurrent_SwiftUI
struct Screen1: View {
@State var shouldProceed = false
@State var shouldAbandon = false
@State var shouldBackUp = false
var body: some View {
VStack {
Text("This is \(String(describing: Self.self))")
Button("Navigate forward") { shouldProceed = true }
Button("Navigate backward") { shouldBackUp = true }
Button("Abandon") { shouldAbandon = true }
}
.workflowLink(isPresented: $shouldProceed, value: "my string")
.backUpInWorkflow($shouldBackUp)
.abandonWorkflow($shouldAbandon)
.shouldLoad { true }
}
} |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I'm quite convinced we have yet to nail down an appropriate SwiftUI API. We have gotten closer, but we lack some features and we lack some focus. I am quite confident we can do better.
Motivation
As it stands, our SwiftUI implementation is complicated, not only because of recursive views but because we are dealing with this underlying
Workflow
reference type. It's also not extensible. Apple broke the NavigationLink contract we used in SwiftUI 4...the code compiles but navigation doesn't work. We're hamstrung releasing something new because GitHub runner aren't on the latest OS and our consumers can't make it work because there's not a great place for them to extend functionality.We also had this notion that "we want views to work whether they're in a Workflow or not." which is counter to how SwiftUI works in general. A
ScrollViewReader
only works in aScrollView
. We need to shed some expectations that only exist because "that's how UIKit did it." So I'm taking a stronger stance with this pitch.Goals
_workflowPointer
FlowRepresentable
so that it's either unnecessary, or only necessary for certain circumstancesshouldLoad
so that it can be placed inside a view, but can also be placed outside that view in theWorkflowView
WorkflowGroup
outside aWorkflowView
definition, thus allowing workflows to be extracted, named, and reused.WorkflowItem
display in a modal, nav link, or any custom context (like a custom built bottom drawer)abandon
so that it becomes more efficient and simpler.WorkflowReader
type to replace the need for_workflowPointer
there's enough convention on this that a discussion regarding that type shouldn't be all the necessary. The last discussion Proposal: FlowRepresentableView #123 did not result in a conversation that helped move this forward, but may provide insight into there being better naming conventions or documentation.I'll be working on this as I have time, after I know whether it even works I'll submit a PR and we can tailor this discussion to reality of the thing, rather than a hypothetical, which I think hindered us last time.
Beta Was this translation helpful? Give feedback.
All reactions