-
Notifications
You must be signed in to change notification settings - Fork 19
-
Data Driven Workflows
No due date Last updated over 2 years agoIf you've got an idea that really works, take that idea as far as i…
If you've got an idea that really works, take that idea as far as it will go, right??? Well, Workflows WORK, they work so well and provide such configurability that there's really no reason to stop at defining them in Swift. We could create a specification in JSON and/or YAML and have that define a workflow. The app could consume that specifically and dynamically create them.
The available
FlowRepresentable
items would have to be driven from the AST output of the Swift code, and there'd have to be some kind of linter to enforce the same kinds of things we have the Swift compiler enforcing, but there's really some interesting things you could do with this.Think about the white-label capabilities this would enable, you could define all kinds of workflows for an app. Take it even further, there's no reason a server couldn't ultimately drive this meaning that you could change a workflow to suit the needs of a business without redeploying an app. I don't believe this really even fundamentally violates the Apple Review Guidelines because we're not talking about fundamentally changing the behavior of an app at all, simply the workflows it launches, it has all the exact same capabilities.
We know we are successful with this milestone when:
- There is a clear, versioned specification for creating a workflow with common configurations (e.g. JSON, maybe YAML)
- Workflows can be created at runtime from that specification
- Workflows are safely created, if the spec asks for
FlowRepresentable
s that simply don't exist, the Workflow cannot create. - The API space makes it abundantly clear that creating a Workflow from data could fail, and gives consumers a way to deal with that (throwing, compile-time errors, something....)
- We have tested Workflows of absurd sizes and have some minimum support for that (a 1,000 item Workflow seems a little ludicrous right now, let's at least have tests and support for that, scale that up as far as you feel you reasonably can, a million item Workflow? If the tests don't take too long, sure!)
- Our sample app is updated to make use of these data driven workflows, perhaps that's local configuration like white-labeling or server-driven configuration just to showcase that it's possible and how cool it is.
-
A Great Testing Experience
No due date Last updated almost 3 years agoThere's an issue open for this but I think it's more of a milestone…
There's an issue open for this but I think it's more of a milestone. WWT believes strongly in good testing practices. We value TDD, a robust automated test harness, and fast feedback. SwiftCurrent shouldn't just be a joy to use to enable powerful, flexible production code. It should also provide a really great testing experience.
Maybe this means a new package designed specifically for testing, maybe it just means writing code that is friendly to test, that's for the team to figure out.
We know we've succeeded at this milestone when there's an easy-to-use API for testing workflows (as quantified by usability tests). At minimum it should include things like:
- asserting that the correct workflow was launched
- asserting that a workflow abandons
- asserting that a
FlowRepresentable
proceeded - asserting that a
FlowRepresentable
backed up - having a friendly end-to-end experience that moves through a workflow and finishes.
-
SwiftUI Support
No due date Last updated almost 3 years agoWorkflows fit so naturally with the idea of composition. SwiftUI is…
Workflows fit so naturally with the idea of composition. SwiftUI is of course completely composition based. SwiftUI is also completely unfriendly if you're handling workflows. Navigation stack modification is tricky at best and SwiftUI actually makes the whole problem of one screen having to know what is next far worse.
SwiftCurrent can step in, provide composable behavior with Workflows, and solve those problems and we're interested in giving a great user experience around management of this.
We know this milestone is successful when:
- We have an example app showcasing best practices (including testing) for SwiftCurrent with SwiftUI
- We have getting started documentation showcasing how to quickly get started with SwiftCurrent_SwiftUI
- The workflow by default is capable of proceeding and backing up, skipping screens, and handling the same flow persistences as UIKit
- Modal workflows in SwiftUI are supported
- Navigation workflows in SwiftUI are supported
- Workflows that switch between modal presentation and navigation stack presentation are supported
- Workflows can launch (modally) a navigation stack
Things we should think about, but maybe deserve their own milestone due to size:
- Workflows should help bridge between UIKit and SwiftUI where necessary
- It may be that you just use a
UIHostingController
- It may also be that SwiftCurrent just handles it so that if I create a workflow that has
FlowRepresentable
s that areUIViewController
s and different ones that areView
s it "just works"